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 » WebSphere Message Broker (ACE) Support » Design opinion

Post new topic  Reply to topic Goto page 1, 2  Next
 Design opinion « View previous topic :: View next topic » 
Author Message
kash3338
PostPosted: Mon Nov 05, 2012 10:10 pm    Post subject: Design opinion Reply with quote

Shaman

Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India

Hi, I have a design which has two MQ Input nodes in it. The first MQInput node is at the statr of the message flow and there are few processing nodes after that and there is one more MQ input node attached to a compute node in the middle of the flow.

Is it OK to have such a design? Basically we could have had two different flows, but the processing done after a compute node is same for both the flows and hence we have a MQInput node attached in between the flow. Is it OK to have such a flow, is there any side-effect for this?
Back to top
View user's profile Send private message Send e-mail
elvis_gn
PostPosted: Mon Nov 05, 2012 10:18 pm    Post subject: Re: Design opinion Reply with quote

Padawan

Joined: 08 Oct 2004
Posts: 1905
Location: Dubai

Hi kash3338,
kash3338 wrote:
Hi, I have a design which has two MQ Input nodes in it. The first MQInput node is at the statr of the message flow and there are few processing nodes after that and there is one more MQ input node attached to a compute node in the middle of the flow.
It's been a while but I don't remember MQInput node having any input terminals

I think you meant to have a part of the flow receiving an MQInput OR a direct connection from the compute to the node after the 2nd MQInput node.

The above mentioned should technically work, though you might have some business issues.

Regards.
Back to top
View user's profile Send private message Send e-mail
kash3338
PostPosted: Mon Nov 05, 2012 10:37 pm    Post subject: Reply with quote

Shaman

Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India

I am sorry I coul;d not give you the exact picture of the message flow. Actually it looks some thing like below,

MQInput --> Compute1 --> FlowOrder (Path2 of floworder)--> Filter1 --> Compute2 --> Subflow1 --> Filter2 --> Subflow2 --> Floworder2 (Path1 of floworder) --> MQOutput

this is the main flow and I have another MQInput node which is directly connected to Comput2. Its done because after compute2 its a same set of processing that needs to be done for all kinds of messages. hence instead of having a separate flow, we have such a design.
Back to top
View user's profile Send private message Send e-mail
fjb_saper
PostPosted: Mon Nov 05, 2012 11:36 pm    Post subject: Reply with quote

Grand High Poobah

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

Compute 2 should be part of subflow1.

This would give you


Code:
                         Floworder-1 -->                                -->                 MQOutput
MQInput --> Compute1 --> FlowOrder-2
                                     --> Filter1 -->  Subflow1 --> Filter2 --> Subflow2 --> (MQOutput of Floworder-1)
                                     MQInput2--^(to subflow1)


Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
tip.1020
PostPosted: Tue Nov 06, 2012 1:50 am    Post subject: Reply with quote

Novice

Joined: 25 Oct 2012
Posts: 10

kash3338 wrote:
I am sorry I coul;d not give you the exact picture of the message flow. Actually it looks some thing like below,

MQInput --> Compute1 --> FlowOrder (Path2 of floworder)--> Filter1 --> Compute2 --> Subflow1 --> Filter2 --> Subflow2 --> Floworder2 (Path1 of floworder) --> MQOutput

this is the main flow and I have another MQInput node which is directly connected to Comput2. Its done because after compute2 its a same set of processing that needs to be done for all kinds of messages. hence instead of having a separate flow, we have such a design.


Hi,
Using two queues means that your message flow will have two input queues to be triggered.
Also what kind of logic are you trying to implement through your messageflow?
Since you are planning to use 2 input queues,I assume that
1)You are trying to handle inputs from two different applications through two seperate queues.
2)If that is the case, then try to handle it through one queue.I am not sure whether this option may be viable to you unless you are aware the type of inputs your are planning to handle(eg:- xml's having different structure of tags)
Back to top
View user's profile Send private message Send e-mail
kash3338
PostPosted: Tue Nov 06, 2012 2:31 am    Post subject: Reply with quote

Shaman

Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India

tip.1020 wrote:
Using two queues means that your message flow will have two input queues to be triggered.


Yes I have two different queues to trigger my flow. One will run the complete flow and the other starts from the middle.

tip.1020 wrote:
Also what kind of logic are you trying to implement through your messageflow?


I have a huge Message Flow which has a XML input message (say Msg1) and half of the logic in this Message Flow should be done for another kind of input message (say Msg2) which is also an XML. Hence I have one MQInput at the beginning and the other in the middle (with a diff Queue which gets Msg2)

tip.1020 wrote:

1)You are trying to handle inputs from two different applications through two seperate queues.


Yes

tip.1020 wrote:

2)If that is the case, then try to handle it through one queue.I am not sure whether this option may be viable to you unless you are aware the type of inputs your are planning to handle(eg:- xml's having different structure of tags)


They are different XML messages. Msg1 will be transformed to Msg2 when it reaches the middle of the flow.[/b]
Back to top
View user's profile Send private message Send e-mail
tip.1020
PostPosted: Tue Nov 06, 2012 2:52 am    Post subject: Reply with quote

Novice

Joined: 25 Oct 2012
Posts: 10

kash3338 wrote:
They are different XML messages. Msg1 will be transformed to Msg2 when it reaches the middle of the flow.


Ok, just as you are aware of the both message structures , I think that I queue is sufficient.
When the flow is triggerred,
1)check for the message xml (identify whether it is of type Msg1 or Msg2)
Check for any distinct xml tag from both type of xml's.
2)use filter node OR any other routing mechanism to process the incoming xml's.
Apply your processing logic based on whether it is Msg1 xml or Msg2 xml.

Hope this helps.
Back to top
View user's profile Send private message Send e-mail
kash3338
PostPosted: Tue Nov 06, 2012 5:37 am    Post subject: Reply with quote

Shaman

Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India

tip.1020 wrote:

1)check for the message xml (identify whether it is of type Msg1 or Msg2)
Check for any distinct xml tag from both type of xml's.
2)use filter node OR any other routing mechanism to process the incoming xml's.
Apply your processing logic based on whether it is Msg1 xml or Msg2 xml.


Thanks for the suggestion, but I guess it adds a overhead in my flow to check for the message type and route. I just want to know the issues on my design?
Back to top
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Tue Nov 06, 2012 5:51 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The only real issues with two input nodes is that it's automatically additional instances, and that you can potentially run into issues when tracing things to not get different instances confused during trace analysis.

User trace does include thread information, so you can sort them out, but you have to keep it in mind.

Neither of these are actual *problems* in any sense.
Back to top
View user's profile Send private message
nathanw
PostPosted: Tue Nov 06, 2012 8:59 am    Post subject: Reply with quote

Knight

Joined: 14 Jul 2004
Posts: 550

The question I have is what are the planned throughputs?

Do we have any expected numbers?

If they are higher for one that the other I would say use separate flows as having a single flow processing 2 different sets of messages may cause overhead issues.
_________________
Who is General Failure and why is he reading my hard drive?

Artificial Intelligence stands no chance against Natural Stupidity.

Only the User Trace Speaks The Truth
Back to top
View user's profile Send private message MSN Messenger
mqjeff
PostPosted: Tue Nov 06, 2012 9:01 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

nathanw wrote:
The question I have is what are the planned throughputs?

Do we have any expected numbers?

If they are higher for one that the other I would say use separate flows as having a single flow processing 2 different sets of messages may cause overhead issues.


Not when you can allocate separate thread pools for each MQInput node.
Back to top
View user's profile Send private message
nathanw
PostPosted: Tue Nov 06, 2012 9:13 am    Post subject: Reply with quote

Knight

Joined: 14 Jul 2004
Posts: 550

mqjeff wrote:
nathanw wrote:
The question I have is what are the planned throughputs?

Do we have any expected numbers?

If they are higher for one that the other I would say use separate flows as having a single flow processing 2 different sets of messages may cause overhead issues.


Not when you can allocate separate thread pools for each MQInput node.


Agreed
_________________
Who is General Failure and why is he reading my hard drive?

Artificial Intelligence stands no chance against Natural Stupidity.

Only the User Trace Speaks The Truth
Back to top
View user's profile Send private message MSN Messenger
tip.1020
PostPosted: Tue Nov 06, 2012 9:10 pm    Post subject: Reply with quote

Novice

Joined: 25 Oct 2012
Posts: 10

kash3338 wrote:


Thanks for the suggestion, but I guess it adds a overhead in my flow to check for the message type and route.


Only a few lines of code will be enough...Although its upto you...

kash3338 wrote:
I just want to know the issues on my design?

No design issues as such..Also how are you planning to implement error handling?
Are you planning to add trace files for catch and failure terminal to each of the MQInputs?
Then here you might have overheads in your flow....
Back to top
View user's profile Send private message Send e-mail
mayheminMQ
PostPosted: Thu Nov 08, 2012 5:31 am    Post subject: Reply with quote

Voyager

Joined: 04 Sep 2012
Posts: 77
Location: UK beyond the meadows of RocknRoll

Have you considered a scenario where the requirements for the first part of the flow might change while the second remains the same?

In this case you will have to bring down the entire flow to make the changes and redeploy when the second MQ Input Node flow could have been running all along..

Simpler design.. unless the sequencing of messages coming in first and second MQ input node is not a problem, just do the change to the first mqinputnode's xml and plainly dump it into the next q. The second part of your flow could be a standalone msgflow reading everything. You have made ur flow modular and easier to make changes.

Coming to ur original point.. There are no problems in ur flow.. just tat it doesnt appear to be long term solution.
_________________
A Colorblind man may appear disadvantaged but he always sees more than just colors...
Back to top
View user's profile Send private message
kash3338
PostPosted: Thu Nov 08, 2012 6:09 am    Post subject: Reply with quote

Shaman

Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India

mayheminMQ wrote:
Coming to ur original point.. There are no problems in ur flow.. just tat it doesnt appear to be long term solution.


Thanks for your reply. The format wont be changing unless we take that decision as its a internal format.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Design opinion
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.