| Author |
Message
|
| princedeepak |
 Posted: Fri Apr 26, 2013 4:12 am Post subject: Need Help in Understanding the Concept of MRM (TDS) |
 |
|
Novice
Joined: 10 Apr 2013
Posts: 16
|
This is my Message Flow 
I am trying to incorporate a (MRM)TDS messageset, in my MQ. And My Message Flow is
as sending one CustomTDS message through MQ and Throught Compute Node Transforming it to the XML to an another MQ.And also I Have Corresponding Catch And Failure Nodes.
For Example if i pass a correct message , it passes through correctly to the Output MQ
and if i pass a incorrect message, I checked through breakpoint in debugger , and it goes to compute node and then only it throws back to the Catch Node
Is this Right way or there is something wrong with this flow..
I am having a doubt , that the message node should be stopped at the input node itself or otherway around.
Thanks in Advance. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Apr 26, 2013 4:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Message Broker forum.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Apr 26, 2013 5:00 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
First, turn off the interactive debugger.
Second, put four Trace nodes in.
| Code: |
Root:
${Root}
===
LocalEnvironment:
${LocalEnvironment}
===
Environment:
${Environment}
===
ExceptionList:
${ExceptionList}
===
${CURRENT_TIMESTAMP}
======================= |
Third, in your Compute node, SET OutputRoot = InputRoot.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 26, 2013 5:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
First, turn off the interactive debugger.
Second, put four Trace nodes in.
| Code: |
Root:
${Root}
===
LocalEnvironment:
${LocalEnvironment}
===
Environment:
${Environment}
===
ExceptionList:
${ExceptionList}
===
${CURRENT_TIMESTAMP}
======================= |
Third, in your Compute node, SET OutputRoot = InputRoot. |
Good advice that will do nothing to change the validation of the message on the input node.
princedepepak - the Input node has a Validation tab. The properties on this control when the physical bitstream is parsed into the logical message tree, and determine what level of adherency to the message model is applied when that occurs. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Apr 26, 2013 6:02 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Message flows default to 'on demand' parsing. They do not bother to parse the input message unless the message flow tries to reference a field in the message. Then the parser runs until that field is available ( in the message tree ) and stops until some other field is required.
If you want parsing to occur earlier, set 'Parse Timing' to 'Immediate' on the input node properties. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Apr 26, 2013 6:03 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| One more thing...your task would be much easier with WMB v8 and the DFDL parser. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Fri Apr 26, 2013 12:42 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
Using the debugger is working for me. Use traces if you like.
Note that parsing on demand will make your interface more "streaming" the data (as opposed to blocking), which can make a (significant) difference for performance. There are plattforms, where exactly this (streaming) is considered the key contribution to their success (e.g. Unix/Linux pipes ("|")). Broker provides that also and its up to your profession to properly use/apply it. I think it is also a/the key contributing factor to broker's success.
Remember that the debugger triggers an immediate parse (of the message tree), but (when you leave on "on-demand-parsing", which I higly recommend  ) your flow will run "differently" in production. Probably because of this (significant) difference, experienced people tend to detach it and use traces (which give a better picture of the on-demand-parsing-behavior of the flow).
Always think and trade where to put validation (message set v.s (ESQL) code). E.g. we tend to define structures/groups and elements in the message set, but keep the elements "untyped" (as string/CHAR) and do the simple type conversions (CASTS) in code.
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 26, 2013 3:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| Using the debugger is working for me. Use traces if you like. |
No one says it doesn't work. Just that it has it's limits.
| mqsiuser wrote: |
| Remember that the debugger triggers an immediate parse (of the message tree), but (when you leave on "on-demand-parsing", which I higly recommend ) your flow will run "differently" in production. Probably because of this (significant) difference, experienced people tend to detach it and use traces (which give a better picture of the on-demand-parsing-behavior of the flow). |
Speaking. Along with everyone else who advocates the user of user trace over debugger. Remember this forum is supposed to be passing on the wisdom of experience.
| mqsiuser wrote: |
| Always think and trade where to put validation (message set v.s (ESQL) code). E.g. we tend to define structures/groups and elements in the message set, but keep the elements "untyped" (as string/CHAR) and do the simple type conversions (CASTS) in code. |
I can hear @kimbert grinding his teeth. Why not exploit the ability of broker to define types via message set or DFDL (according to version) but write code to do this? Aside from the extra lines of code & maintenance, why spend machine resource building a message tree only to rework the message tree later?
Obviously there are instances where there's no alternative but to validate in code but if you have data sufficiently strongly typed I don't see the advantage of not exploiting WMB. Cite your sources and your reasoning. Share your wisdom of experience.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Sat Apr 27, 2013 8:21 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
mqsiuser said:
| Quote: |
| Remember that the debugger triggers an immediate parse (of the message tree), but (when you leave on "on-demand-parsing", which I higly recommend ) your flow will run "differently" in production. |
That was true up to v6 FP<big number> but from v7 onwards that problem has been fixed.
It does force a full parse, of course, or else it could not display the tree in the debugger. But it does that on a copy of the message so that the message flow logic is not affected. |
|
| Back to top |
|
|
| kimbert |
| Posted: Sat Apr 27, 2013 8:25 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| I can hear @kimbert grinding his teeth. |
Not really. If mqsiuser wants to do it that way then he's welcome to. There are others who agree with him. However, the majority of message flow designers do exploit the ability of message broker to validate the messages, and so would I, unless there was a good reason to hand-code it all. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Apr 27, 2013 10:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kimbert wrote: |
| Quote: |
| I can hear @kimbert grinding his teeth. |
Not really. If mqsiuser wants to do it that way then he's welcome to. There are others who agree with him. However, the majority of message flow designers do exploit the ability of message broker to validate the messages, and so would I, unless there was a good reason to hand-code it all. |
But all your work! All that beautiful parsing! It's like using a 1" brush instead of a roller to paint a wall.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Sat Apr 27, 2013 10:32 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| Vitor wrote: |
| ... to rework the message tree later? |
That will not happen: CASTs will go directly to the OutputRoot.
| Vitor wrote: |
| Obviously there are instances where there's no alternative |
We all know that DATE/DATETIME is a typical instance for taking in as String and doing a CAST (or actually substrings) in code.
| Vitor wrote: |
| ...but to validate in code but if you have data sufficiently strongly typed I don't see the advantage of not exploiting WMB. |
In code you can do custom handling (e.g. your own exception-text or "hand through" invalid dates (e.g. 2013-02-31) if the attached partner(s) want/require that).
If you send back errors (exceptions) to your customer, you will likley want to have that (your own error/exception text). Though you might also achieve this differently. You don't want to send them "Error in parse next".
1. I found the build-in exception-texts from ESQL-code better (e.g. CAST-Exceptions)
2. And they are easily customizable if required (compared to the ones from the parser): Before anyone complains/throws, you just (make your own checks (based on your business requirements) and) throw your own exception (including text). No need to catch some other exception (and trying to deal (adjust and rethrow ?!) with that).
That has to do with, that in code you can just easily programm anything you like, while a message set and parser are more "tied together" (by concept) (no offense towards anyone )
@kimbert: Good work on the debugger 
I really appreciate that Hursley supports a wide range of approches (including mine).
But its just about simple types: Do it in the msg set or in code. Nobody gets hurt significantly: Performance, Maintainability.
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| kimbert |
| Posted: Sun Apr 28, 2013 12:21 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| But all your work! All that beautiful parsing! It's like using a 1" brush instead of a roller to paint a wall. |
This isn't strictly about parsing ( converting a string of bits/bytes into a logical message tree ). It's about validation. The two often get confused, because they are sometimes performed by the same component.
To be fair to mqsiuser and goffinf, they are aiming for *more* precision in the messages that are emitted when the validation fails. That's a valid requirement, and one that DFDL addresses by allowing a DFDL assert or discriminator to emit a user-specified message when they fail. |
|
| Back to top |
|
|
| princedeepak |
| Posted: Sun Apr 28, 2013 9:22 pm Post subject: Thank you all for your valuable feedback... |
|
|
Novice
Joined: 10 Apr 2013
Posts: 16
|
| Thank you all for your valuable feedback.It helped me a lot |
|
| Back to top |
|
|
| princedeepak |
| Posted: Tue Apr 30, 2013 6:23 am Post subject: |
|
|
Novice
Joined: 10 Apr 2013
Posts: 16
|
I am getting the following error can someone suggest me a solution.
ImbRecoverableException caught from worker->parseNext. |
|
| Back to top |
|
|
|
|
