Author |
Message
|
kash3338 |
Posted: Mon Nov 05, 2012 10:10 pm Post subject: Design opinion |
|
|
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 |
|
|
elvis_gn |
Posted: Mon Nov 05, 2012 10:18 pm Post subject: Re: Design opinion |
|
|
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 |
|
|
kash3338 |
Posted: Mon Nov 05, 2012 10:37 pm Post subject: |
|
|
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 |
|
|
fjb_saper |
Posted: Mon Nov 05, 2012 11:36 pm Post subject: |
|
|
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 |
|
|
tip.1020 |
Posted: Tue Nov 06, 2012 1:50 am Post subject: |
|
|
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 |
|
|
kash3338 |
Posted: Tue Nov 06, 2012 2:31 am Post subject: |
|
|
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 |
|
|
tip.1020 |
Posted: Tue Nov 06, 2012 2:52 am Post subject: |
|
|
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 |
|
|
kash3338 |
Posted: Tue Nov 06, 2012 5:37 am Post subject: |
|
|
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 |
|
|
mqjeff |
Posted: Tue Nov 06, 2012 5:51 am Post subject: |
|
|
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 |
|
|
nathanw |
Posted: Tue Nov 06, 2012 8:59 am Post subject: |
|
|
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 |
|
|
mqjeff |
Posted: Tue Nov 06, 2012 9:01 am Post subject: |
|
|
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 |
|
|
nathanw |
Posted: Tue Nov 06, 2012 9:13 am Post subject: |
|
|
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 |
|
|
tip.1020 |
Posted: Tue Nov 06, 2012 9:10 pm Post subject: |
|
|
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 |
|
|
mayheminMQ |
Posted: Thu Nov 08, 2012 5:31 am Post subject: |
|
|
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 |
|
|
kash3338 |
Posted: Thu Nov 08, 2012 6:09 am Post subject: |
|
|
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 |
|
|
|