ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » ESQL for beginners

Post new topic  Reply to topic
 ESQL for beginners « View previous topic :: View next topic » 
Author Message
mqmike
PostPosted: Sun Feb 21, 2010 12:14 pm    Post subject: ESQL for beginners Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Sun Feb 21, 2010 12:27 pm    Post subject: Re: ESQL for beginners Reply with quote

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
View user's profile Send private message
mqmike
PostPosted: Sun Feb 21, 2010 12:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
kimbert
PostPosted: Sun Feb 21, 2010 1:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
mgk
PostPosted: Sun Feb 21, 2010 1:32 pm    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Sun Feb 21, 2010 2:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Sun Feb 21, 2010 2:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Sun Feb 21, 2010 11:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » ESQL for beginners
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.