| Author |
Message
|
| mqmike |
 Posted: Sun Feb 21, 2010 12:14 pm Post subject: ESQL for beginners |
 |
|
Acolyte
Joined: 09 Jul 2004
Posts: 63
|
Can someone please tell me where I'm going wrong with this one
Input message is xml, let's say...
<Message>
<Name>John</Name>
</Message>
Output needs to be...
<Output>
<Handle>John</Handle>
</Output>
ESQL (MQInput - Compute - MQOutput)...
set OutputRoot.MQMD = InputRoot.MQMD;
set OutputRoot.Properties.MessageFormat = 'XML';
set OutputRoot.XMLNSC.Output.Handle = InputRoot.XMLNSC.Message.Name;
Result ends up as...
<Output/>
I've tried explicity using create field, including/not including xml declarations and same with set OutputRoot.Properties.MessageFormat = 'XML'; |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sun Feb 21, 2010 12:27 pm Post subject: Re: ESQL for beginners |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqmike wrote: |
Can someone please tell me where I'm going wrong with this one
|
Someone can; their name is User Trace and they live in the broker. 
Seriously, when faced with this situation Action 1 is to take a user trace and see exactly what's going on. I'm guessing the XML has been simplified for posting purposes so one possible explaination is a mismatch in namespaces. Even if you don't believe there are any namespaces involved.
(My working hypothsis here is that your input reference is resolving to a null. That could be because it's Sunday afternoon and I'm feeling really good. And somewhat unstable.)
So your next step is to take a user trace. If nothing stands out, post the trace (in code tags if you please) along with the actual ESQL snippet.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqmike |
| Posted: Sun Feb 21, 2010 12:40 pm Post subject: |
|
|
Acolyte
Joined: 09 Jul 2004
Posts: 63
|
| Thanks - I'll see what that unearths. I thought there may be something glaringly obvious that was wrong but maybe not. Doesn't bode well if I'm having to take traces just to copy an element's value to another field! |
|
| Back to top |
|
|
| kimbert |
| Posted: Sun Feb 21, 2010 1:06 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Doesn't bode well if I'm having to take traces just to copy an element's value to another field! |
When learning a new programming language, it is quite usual to make mistakes with simple tasks. Sometimes you can blame the language or the programming environment. Other times, it's just part of the learning process.
I recommend that you use the following guidelines when debugging a message flow:
- use the debugger for simple inspection of message flow behaviour
- if the problem is not immediately obvious, disconnect the debugger and take a user trace. Do this especially and always if the problem is connected with parsing or writing of the message.
- use Trace nodes when taking a user trace. The output goes into user trace by default, so you get a full picture of what the message flow is up to.
User trace has the following advantages:
- it explains what the message flow is attempting to do ( including but not limited to ESQL execution )
- it contains the full text of all error messages issued by the flow ( not just the bare exception list )
- it contains information which is simply not available from the debugger, or anywhere else.
Don't think of it as a 'service trace' ( something for diagnosing faults in the product ). It's a user trace - a text output which is designed to assist developers with the debugging of message flows. |
|
| Back to top |
|
|
| mgk |
| Posted: Sun Feb 21, 2010 1:32 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
In case it makes you feel better, I can confirm that given the Input and Output messages above, your ESQL to copy the value across is correct:
| Code: |
| set OutputRoot.XMLNSC.Output.Handle = InputRoot.XMLNSC.Message.Name; |
As suggested above, the reason you are seeing an empty tag as output is that the Input "Name" element must not exist (so NULL is assigned to the Output). There are a couple of things that spring to mind that could easily cause this. The first is that the input message to the flow is wrong and "Name" does not exist in the location you expect or that the message is not actually in the XMLNSC domain - have you made sure that the Domain on the Input node that started this flow has been set to XMLNSC and not XML or XMLNS?
Also assuggested above a UserTrace will help show what is going wrong in great detail  However as kimbert suggests a Trace node after the Input node would be the quickest way of checking the message tree "shape" is as you expect it to be.
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Feb 21, 2010 2:12 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I have a development flow that has the following config
MQInputNode-->TraceNode
I use this to test the development of my message models. The trace node is used to output the message tree after being parsed by the InputNode.
This also reveals a lot of useful information about the test messages you might have to use in development. Sometimes they might not actually match the model/xsd you are given!!!@@@******!!!!
Until the message(s) can be parsed/validated correctly against the model/xsd it is not worth spending huge amounts of time trying to debug the real flow in later nodes.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Feb 21, 2010 2:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqmike wrote: |
| Doesn't bode well if I'm having to take traces just to copy an element's value to another field! |
Why? 
There are a lot of potentially complex issues in parsing a message into the tree, then manipulating it.
There are also times you just need to take a trace to highlight the glaringly obvious mistake you've made. It happens.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sun Feb 21, 2010 11:12 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
| mqmike wrote: |
| Doesn't bode well if I'm having to take traces just to copy an element's value to another field! |
Why?
There are a lot of potentially complex issues in parsing a message into the tree, then manipulating it.
There are also times you just need to take a trace to highlight the glaringly obvious mistake you've made. It happens. |
I have to agree with Vitor here. There are times in any software development where you can be faced with a simple problem that is staring you in the face and you can't see it...
That said, this topic is titled "ESQL for Beginners". If you are a beginner then the advice given is very important. When you get experienced, you won't need to do so many things that might seem so elementary.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
