| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| selective get from a Queue based on Correaltion ID |
« View previous topic :: View next topic » |
| Author |
Message
|
| kshah |
 Posted: Thu Jul 13, 2006 10:24 pm Post subject: selective get from a Queue based on Correaltion ID |
 |
|
Novice
Joined: 13 Jun 2005
Posts: 23
|
HI..guys..
I m faced by a typical design problem...where we are designing an EAI architecture.We are using WBIMB 6 and MQ Series 6.
Now are scenario is such that we have 31 backend applications involving SAP Siebel Ariba...n legacy systems as well.
We are designing are MAin Router flow which will do the transformation from Application specific buisness Object (ASBO) to Generic business object (GBO) and then to convert GBO to target ASBO we have application specfic flow doing tht.
Hence we would required 31 queues for this 31 flows.
N Now the real problem is we dont want a 31 queus....for 31 flows..can we have somtthinh like a single queue where each flow is polling..n then do a selective get..based on some field...
presently we are thinking of solution where we change the correlation id n give a hexdecimal number which is paricular to a flow n hence..then MQ Input node gets the messge based on this Corr ID..n later on replace this with orignal corr id which wil b available in header.
This are just are intial thoughts..can some one suggest..us.whether this approach of selective get based on corr ID is advisable..?
Can we do a selective get based on any other field..apart from Message ID or Corr ID?
As we are using latest Mesage Broker version 6 n MQ 6...do we have some added feature which we can leverage here?
also...one note that the client whats all the backend applications flows to be separate flow n doent want to have all as subflows binded to a master flow whihc routes to the application specific sub flow.
Only solution we cud think of is do a selective get...if ne of u folks can share ur expertise or knowledge it wud b realyy great for us.
Thnks...for ur time..Guys.. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Jul 14, 2006 1:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In my opinion, having one queue instead of 31 is not "better". In fact, it can be more confusing. It is "better" to have as many queues as provide a good logical view of the processing, and as provide good fault isolation. So that if you get an alert that queue X is getting full - you know as much as possible about what's broken and who's affected just from the fact that it's queue X and not queue Y.
If the flow is doing all of the transformations from ASBO to GSBO and then to ASBO again, it's not necessarily a "router" flow - it seems to be doing all the work in one big thing. In this case, I might even suggest that you have 32 flows. One each to handle ASBO->GSBO and GSBO->ASBO for each application, and one to route between them based on GSBO or maybe a more generic format than that.
Also, in my opinion, it is not a good idea to use message Id or correlation ID to hold business information like you are thinking of. These fields are not necessarily large enough to hold all the data you might want, they are always treated as binary values, and it can make less explicit information that should be more explicit.
You can't do selective gets based on any fields other than msgid and corrid. You can use MB to understand the full data of the message, and make decisions based on any field in the message.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| shrek |
| Posted: Tue Jul 18, 2006 3:35 am Post subject: |
|
|
Acolyte
Joined: 19 Feb 2005
Posts: 61
Location: Gudivada,India
|
| I agree with jeff. We should not be using MessageId or CorrelationId to store business data. Thanks |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
