| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Design - Best Practice |
« View previous topic :: View next topic » |
| Author |
Message
|
| IntegratorWMB |
 Posted: Thu Dec 06, 2007 12:18 pm Post subject: Design - Best Practice |
 |
|
Apprentice
Joined: 06 Dec 2007
Posts: 27
|
Here is an existing process which we are designing as a flow in WMB
a) message comes in to a queue
Note : Initial message does not contain all the data.
b) based on the content of the message, several round trips is made to mainframe to enrich the data content
c) message is transformed
d) message is send to a queue
I thought of designing it as an
--MQINPUTNODE -- COMPUTENODE1 -- COMPUTENODE2 -- MQOUTPUTNODE
In ComputeNode1
we will have java code that has the business logic to query for which data from the mainframe. I do know that we have keep the business logic out of the flow. But current process doesn't allow it.
Also the current process cannot aggregate all the information before giving it to message broker.
Moreover in computenode1 I am connecting to mainframe using mq(several roundtrips are made to mainframe because the logic requires to forming the next request is based on the resposne received ).
I am wondering whether having the compute node as a sub-flow will help? Also what would be the impact if I use MQGet Node to do the round trips as part of the flow? |
|
| Back to top |
|
 |
| Bill.Matthews |
| Posted: Fri Dec 07, 2007 5:17 am Post subject: |
|
|
Master
Joined: 23 Sep 2003
Posts: 232
Location: IBM (Retired)
|
Some thoughts - and questions for you:
1. Keep in mind that a subflow is use for development reasons and becomes inline ar runtime. So that is immaterial.
2. You ask whether or not the use of an MQGet would have an "impact". For this, one would have to ask - do you assume that you can write more efficient code in your JavaCompute node to do the same task? Fi so, great - just realize that you are adding unnecessary development costs.
3. Whether or not "business logic" should belong in a message flow or not is a debate that could go on for a long time, so lets ignore that aspect and consider such logic as being part of getting the job doen.
4. This statement:
| Quote: |
| "several roundtrips are made to mainframe because the logic requires to forming the next request is based on the resposne received" |
is the most important. It eliminates the use of the Aggregation Nodes.
5. I would suggest that your solution could be constructed by the following combination of nodes, where there are several paths out of Compute1:
MQInout --> Compute1 --> MQOutput (to MF) --> Compute2 -->MQGet (from MF) --> Compute3
--> Compute4 --> MQOutput (for final msg)
For the first path - I would suggest that you could have a single compute node that setup the 1st msg to the MF, did a propagate to out1, where the msg is sent.. in Compute2, you get the msgid of the sent msg, put it in the CorrelId and pass to the MQGet to do a Get with CorrelId , then end that path with compute3 - where the results of the response are saved in the Environment.
When that path ends, control goes back to the next statement in Compute1 - where you repeat the process and construct the 2nd msg and take the same path again.
When all of the information has been gathered, build the final response, then take a different path out of the Compute1 - and send the response to its queue.
_________________
Bill Matthews |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 07, 2007 5:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
To take this to a higher level of design discussion - if every outbound request requires the aggregated result from all previous outbound requests (including the entire original input message), then you have a state machine, and you need to maintain this state somewhere.
How you choose to maintain that state can have a large impact on how you design your flow.
For example, instead of creating a single flow, using MQGets, you could decide to store the "state" data somewhere else. Then you could have each inbound response go to an MQInput node, which then causes the state to be retrieved and aggregated with the inbound response to generate the "next" outbound request.
Depending on how clever you're feeling, and whether you think it makes the processing too implicit - you could even do this with *one* flow, with *one* MQInput node.
Also, please do not call out to MQ from a JavaCompute node. If you're going to do that, you might as well not use Broker at all and just do everything as a single standalone java program.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
