| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Help required to design flows for message decomposition |
« View previous topic :: View next topic » |
| Author |
Message
|
| chauhangaurav |
 Posted: Thu May 16, 2013 8:39 pm Post subject: |
 |
|
Novice
Joined: 15 May 2013
Posts: 11
|
Aggred with above solution ..but here you are considering input xml will be structured like that it will have different xml stanza used for multiple next requests in message...
but actual Input msg structure is like single xml structure ...
#for first req ...some of its parametrs will be mapped and transformed and send down ...and for second req..another parameters will be mapped...
there no sub parts pre defined in input xml fior all decompostion msgs..
like
<Name>
<a> <<<Child elements of a>>>></a>
<b> <<<Child elements of b>>>></b>
</Name>
u r considering this type of structure <a> part is for first req and suggets to remove <a> part and store rest part in staging queue.
In actual case... for first message to be constructed some elements are to be mapped from <a> part ,some from <b> part and from <c>.....so ...on for same for second and third req. |
|
| Back to top |
|
 |
| dogorsy |
| Posted: Fri May 17, 2013 1:06 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
you can try a synchronous flow:
input msg--> compute node 1 --> request ( soap ? ) --> compute node 2
so, compute node 1 builds the 1st message and propagates to request node ( and waits for reply ), compute node 2 gets reply from soap and sets an Environment.variable = true or false , and returns false (RETURN FALSE;). that should get processing back to compute 1 where you look at the environment.variable and proceed accordingly. when you are finished in compute node 1, propaget to a different terminal the outcome |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Fri May 17, 2013 4:04 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
You've had a lot of suggestions and help. Ther are many ways to skin a cat, but only YOU can decide what design will suit your requirements.
Personally, having got to the stage you are at I would keep it very simple (also I am not keen on long-running message flows with complex orchestration when they could be separate asyncronous flows). Document your transformations and logic for triggering each downstream service call. Then either apply that logic in the syncronous flow that dogorsy advocates or do it asyncronously:
i.e.
[list=]store the original request in flow 1 and send the first downstream request
handle the first reply in flow 2, determine if further processing is required, retrieve the stored original request to augment transformation, and send downstream request 2,
handle the first reply in flow 3, determine if further processing is required, retrieve the stored original request to augment transformation, and send downstream request 3
...
Then finally (or at any point when no further processing is required) retrieve the stored original request to augment transformation, and send the final reply.[/list]
I just think that you may be overcomplicating your processing to do something that should be straightforward and you seem to have too many gaps in understanding e.g. in this quote you seem to be suggesting problems with some sort of loop back to the first flow each time and knowing where you are in the orchestration - hence saying "keep it simple".
| chauhangaurav wrote: |
I also tried with the same logic using.mqget to extract original message in reply flow ..but stuck in part..when after extracting original message and sending original msg back to previous request flow from where first part of msg is sent,,unable to decide on which factor or flag condiion it will deterimine to form 2nd transformed msg .bcos after entering to same,it should not go towards first decomposed transformed logic..some comdition shd be dere to route towards second transformation logic.
Or instead of routing original msg back to previous same req flow from where first msg is generated,,i would make seperate flow to generate second msh.
By doing so,it will increase number of req flows.. |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri May 17, 2013 4:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| chauhangaurav wrote: |
u r considering this type of structure <a> part is for first req and suggets to remove <a> part and store rest part in staging queue.
In actual case... for first message to be constructed some elements are to be mapped from <a> part ,some from <b> part and from <c>.....so ...on for same for second and third req. |
And what did you post that would have caused me to consider differently?
My solution still works, just with more code. You've still also failed to explain why these requests need to be syncronized in this way. Without this requirement your problem becomes trivial so you need to determine if this is a real requirement (i.e. something that must happen for some technical reason) or something management / business have said which doesn't actually make a difference to anything.
I agree with @vmcgloin; you're tying yourself in knots.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
