| Author |
Message
|
| deepak_paul |
 Posted: Tue Mar 16, 2010 7:49 pm Post subject: Which is good design |
 |
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
1. MQInput-->Compute[Store input Msg into Env and form Subflow request]-->Subflow-->Compute[Parse Env tree and combine with Subflow response]-->MQOutput
OR
2. MQInput-->Flow Order[Term1]-->Compute[form Subflow request]-->SubFlow-->Compute[Store Subflow response into Env]
|
[Term2]--> Compute[Process Subflow res in Env]-->MQInput
_________________
Regards
Paul |
|
| Back to top |
|
 |
| elvis_gn |
| Posted: Tue Mar 16, 2010 9:31 pm Post subject: |
|
|
Padawan
Joined: 08 Oct 2004
Posts: 1905
Location: Dubai
|
Hi deepak_paul,
Basically your question becomes, should I develop an asynchronous or a synchronous flow.
Both are possible to do, the decision should be made after considering how critical the availability of the flow is, how much time does the backend request take, what is the throughput required etc.
Regards. |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Tue Mar 16, 2010 9:43 pm Post subject: |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
Elvis_gn,
I would like to expect like
First design has minimal nodes but storing the whole input message and having that env tree being passed to next node is an overhead.
_________________
Regards
Paul |
|
| Back to top |
|
|
| deepak_paul |
| Posted: Thu Mar 25, 2010 7:54 am Post subject: |
|
|
Centurion
Joined: 04 Oct 2008
Posts: 147
Location: US
|
Any other solutions?
_________________
Regards
Paul |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Thu Mar 25, 2010 12:03 pm Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| elvis_gn wrote: |
Hi deepak_paul,
Basically your question becomes, should I develop an asynchronous or a synchronous flow.
|
Really? I cant see that this is where the OP was going with the diagrams supplied above (although its not the easiest one to follow and the MQInput node at the end of leg 2 is confusing also). To me it looks like the second diagram has a flow order node with both its terminals connected but other than that its similar to the first one with nothing making it behave in an asynchonous fashion.
The second diagram looks overly complicated in this scenario and in general i'd probably opt for the first flow as its easier to follow. Each to their own though.
Just out of interest what does your subflow do? If it is making exeternal calls then maybe it would be worth thinking about doing this in an asynchronous manner (which may have been elvis' point). You are more likely to get a bigger benefit from doing that than worrying about the introduction of a flow order node. |
|
| Back to top |
|
|
|
|
