Author |
Message
|
PankajS |
Posted: Tue Oct 25, 2011 5:08 pm Post subject: Can I create Variable FanOuts in Aggregation Flows |
|
|
Voyager
Joined: 27 Dec 2004 Posts: 82
|
Hi,
I need break single incoming request to multiple output requests to backend(in parallel). But the number of requests to back-end can vary from 1 to 10 as per the payload. Is this scenario possible to be achieved with Aggregate nodes ? or the Aggregate control node always assumes the fixed number of Fan-Ins ?....and Can i use SOAPAsyncRequest node with FanOut Flow .. OR it has to be MQOutput node only ? |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Oct 25, 2011 7:54 pm Post subject: Re: Can I create Variable FanOuts in Aggregation Flows |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
PankajS wrote: |
Hi,
I need break single incoming request to multiple output requests to backend(in parallel). But the number of requests to back-end can vary from 1 to 10 as per the payload. Is this scenario possible to be achieved with Aggregate nodes ? or the Aggregate control node always assumes the fixed number of Fan-Ins ?....and Can i use SOAPAsyncRequest node with FanOut Flow .. OR it has to be MQOutput node only ? |
I haven't tried it. But I believe if the max # of fan out branches is known and the aggregation is written for the max # of branches it should be possible. I figure a filter node to stop propagation on the non mandatory branches should do the trick...
Of course the fan in part will need to be able to deal with the fact that some of the fan in folders may just not be there...(using references should help)
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
PankajS |
Posted: Tue Oct 25, 2011 8:25 pm Post subject: |
|
|
Voyager
Joined: 27 Dec 2004 Posts: 82
|
thaks .... trying out the same ... BTW ..any one have tried this before ??
Any idea if SOAPAsyncRequest Node can be used ? May be a SOAPAsncResponse node at the start of the Fan-In flow that will feed message to the Aggregate reply node. Not sure .. just in case some one have tried and sure that this setup works. ............ I guess, SOAPRequest node is out of questions as the response will be at the output terminal of the same node (in the same flow.)........... |
|
Back to top |
|
 |
paintpot |
Posted: Wed Oct 26, 2011 3:31 am Post subject: |
|
|
Centurion
Joined: 19 Sep 2005 Posts: 112 Location: UK
|
Yes, this works (variable number of MQ aggregation messages).
If you send a version of the original message directly (so that it is practically guaranteed to arrive), then you can include detail on how many responses you are expecting if that matters to you (useful for error scenarios / error messages). |
|
Back to top |
|
 |
fenway_frank |
Posted: Wed Oct 26, 2011 11:47 am Post subject: |
|
|
 Apprentice
Joined: 21 Oct 2011 Posts: 43 Location: Boston, MA USA
|
@pankajs.. i was faced with a similar use case (control the # of fan-out flows based on inbound msg payload) and took a slightly different approach. in the end, i decided it was adding too much complexity to saddle the fan-out flow with logic to determine when a target sub-flow was to be called. instead, i unconditionally fan-out to all 5 sub flows and added a simple route node within each subflow to introspect content of request then either continue with the sub flow or terminate immediately. i did not use asyncSoapRequestNode in fan-out but used mq instead bcos the soap targets of the fan-out did not support ws-addressing which is key for asyncSoapRequest to function as expected (emphasis on async). this approach has worked well so far. hope it helps. |
|
Back to top |
|
 |
|