| Author |
Message
|
| yellowbee |
 Posted: Sat Feb 02, 2013 2:23 am Post subject: Flow order node |
 |
|
Acolyte
Joined: 14 Apr 2012
Posts: 58
|
In the Flow order node If the first phase of processing fails, the node does not regain control and does not propagate the message through the Second terminal.
My doubt is if any exception or failure occurred while processing the message in second phase,what will happen to the original input message.
Thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sat Feb 02, 2013 4:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Depends on whether the first path committed anything or not... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kash3338 |
| Posted: Sat Feb 02, 2013 6:06 am Post subject: Re: Flow order node |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| yellowbee wrote: |
| My doubt is if any exception or failure occurred while processing the message in second phase,what will happen to the original input message. |
Depends on what your requirement is. What is your requirement? |
|
| Back to top |
|
|
| yellowbee |
| Posted: Mon Feb 04, 2013 9:03 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2012
Posts: 58
|
Thanks Kash..
My Error handling flow is like..
----Sub flow to Roll back changes(First Leg)
|
MqInput Node -> Filter Node | --- Data Base Insertion
----- Filter Node |
---- Response back to sender
My doubt is that if any exception occur at the second leg of the second Flow order Node then, what will happen to the original message . |
|
| Back to top |
|
|
| NealM |
| Posted: Mon Feb 04, 2013 9:10 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Still not real clear to me what you want it to do. But, you could always stick a Trycatch Node as your first node on the 2nd leg and have complete control of what you want to do should the situation occur... |
|
| Back to top |
|
|
| yellowbee |
| Posted: Mon Feb 04, 2013 10:24 am Post subject: |
|
|
Acolyte
Joined: 14 Apr 2012
Posts: 58
|
I mean in my flow there are 2 Flow order nodes are there
in the 1st Flow order node,First leg connected to a sub flow that redirect to Main flow which roll back the changes. the second leg of 1st flow order node is connected to another flow order Node.
in The 2nd flow order node,the first leg is connected to database insertion Node.The Second leg of 2nd flow order node is used to send the error message to the sender of message.
If an exception occurred in fallowing scenarios,Could u explain me what will happen to the input message.
1)If an exception occurred at second leg of 2nd flow order node
2) If an exception occurred at first leg of 2nd Flow order node
Thanks |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 04, 2013 11:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| any transactions that were committed down the first path are still committed when you get to the second path. |
|
| Back to top |
|
|
| NealM |
| Posted: Mon Feb 04, 2013 11:58 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
I'm still not sure what you are after, but:
When your message has a failure, it will be rolled back toward your originating input node, without taking any sidepaths like the First terminal in a floworder node, until it reaches a node in the backtrack that has its Failure terminal wired, and will then follow that path (which, if it in turn fails, will cause the message to continue back to the Input node). If it makes it all the way back to the input node's failure processing, then any transactional , not yet committed happenings on those first flow order legs will be rolled back. And what happens to your input message depends on what your failure processing does then. Backout count/queue, failure terminal path, .....
Here's a suggestion: Since the global Environment does not get rolled back on a failure, use it to set a few status/completion flags down each leg so your failure processing knows what may or may not have been accomplished in the flow. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Mon Feb 04, 2013 6:27 pm Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| You can easily simulate this and debug the flow to know what is happening, and check each and every tree after each use case, that would give you much clear and better understanding than what you read here. Just my suggestion. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 05, 2013 6:15 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| kash3338 wrote: |
| You can easily simulate this and debug the flow to know what is happening, and check each and every tree after each use case, that would give you much clear and better understanding than what you read here. Just my suggestion. |
The interactive debugger is a poor choice here. Try Trace nodes.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kash3338 |
| Posted: Tue Feb 05, 2013 7:51 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| lancelotlinc wrote: |
| The interactive debugger is a poor choice here. Try Trace nodes. |
Accepted, trace nodes are a good choice, but why do you say interactive debugger as a poor choice? Any specific reason? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 05, 2013 8:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kash3338 wrote: |
| why do you say interactive debugger as a poor choice? Any specific reason? |
- the interactive debugger changes the behaviour of the flow it's monitoring, e.g. it completely parses a message tree to display it in the window where the flow typically parses on demand
- the debugger will show you what's happened (the value of a variable) but not how it's happened. Consider if a variable is evaluating to null; the debugger will confirm that it's null (which you know) but not how it failed to be assigned a value.
- not all environments support the interactive debugger. Most production environments have the debugger port closed for security reasons.
This is a representative sample of reasons, not an exhaustive list.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 05, 2013 10:52 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| kash3338 wrote: |
| lancelotlinc wrote: |
| The interactive debugger is a poor choice here. Try Trace nodes. |
Accepted, trace nodes are a good choice, but why do you say interactive debugger as a poor choice? Any specific reason? |
Because its hard to keep track of where you are in the flow, and once you pass the problem area in the interactive state, you have to start all over again. Using a method of debugging in which the interested information is stored is much preferable because the timing is maintained. Some WMB facilities depend on timing. Getting in the habit of using Trace nodes for design and debugging which will save you a boat load of time trying to catch hard to find issues.
All these things in addition to what Vitor said, which was quite visionary.
Some basic rules for Trace nodes:
1. Put a trace node between each major node in your flow.
2. Make sure all terminals are attached to a unique Trace node.
3. Use Throw nodes if needed.
4. Don't put more than one input wire to any Trace node.
5. Make sure each unique Trace node writes to a unique file on disk.
6. Here is an example pattern:
| Code: |
Root:
${Root}
===
LocalEnvironment:
${LocalEnvironment}
===
Environment:
${Environment}
===
ExceptionList:
${ExceptionList}
===
${CURRENT_TIMESTAMP}
======================= |
7. Get good at reading trace files.
8. If your trace files contain PCI or ePHI data, turn them off in Production through the mqsichangetrace command. Trace nodes that are off in Production consume virtually no resources.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| NealM |
| Posted: Tue Feb 05, 2013 12:47 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
| 7. Get good at reading trace files. |
...and of course pay attention to the values on those global Environment variables that I mentioned for you to set, in your trace output.....
 |
|
| Back to top |
|
|
|
|
