| Author |
Message
|
| Memme |
 Posted: Sat Aug 04, 2012 6:51 am Post subject: XML Attribute not set when copying to OutputRoot.XMLNSC |
 |
|
Newbie
Joined: 04 Aug 2012
Posts: 2
|
Hello everyone,
we are having troubles with XML attributes of a message when it is assigned from a local variable (Type:Row) to the OutputRoot.XMLNSC folder.
The coding looks as follows:
DECLARE message ROW;
CREATE LASTCHILD OF message DOMAIN('XMLNSC') PARSE(OutputRoot.XMLNSC.ns:SapZPmEsbWrapper.SapZPmEsb.IServiceinput CCSID 1208);
DELETE FIELD OutputRoot.XMLNSC.*;
SET OutputRoot.XMLNSC = message.XMLNSC;
When the parsed bit stream is set from the variable message to the OutputRoot the attributes are lost. In debug mode we see the attribute present in the message variable.
What we would expect is that all the attributes are set correctly since the parser attached to the OutputRoot is XMLNSC which should support XML attributes. Right?
There seems to be quite some issues with XML attributes in WMB, we found a lot of topics here in the forum. unfortunately none of them helped fixing our problem.
Thanks! |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sat Aug 04, 2012 7:08 am Post subject: Re: XML Attribute not set when copying to OutputRoot.XMLNSC |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Memme wrote: |
| In debug mode we see the attribute present in the message variable. |
But present as attributes, or present as elements of the ROW variable?
| Memme wrote: |
| What we would expect is that all the attributes are set correctly since the parser attached to the OutputRoot is XMLNSC which should support XML attributes. Right? |
Right. What I'm more interested by is that code which assigned the XMLNSC parser to a ROW variable deployed. Clearly there are other posters here who can (and we hope will) comment on the internal workings of WMB with authority.
Take a user trace and see exactly what's happening when that CREATE statement happens. Also try storing the XML in the Environment tree rather than a ROW variable, perhaps just for experimental purposes?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 04, 2012 7:23 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| SET OutputRoot.XMLNSC = message.XMLNSC; |
message is of TYPE ROW. Verify if that type keeps the XMLNSC types... it may well not.
Just to ensure that the types (attributes) stay the same you might have to traverse the tree and find the attribute types and make sure they are (XMLNSC.Attribute).... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kash3338 |
| Posted: Sat Aug 04, 2012 7:45 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| fjb_saper wrote: |
message is of TYPE ROW. Verify if that type keeps the XMLNSC types... it may well not.
|
I guess it will (rather should) keep the XMLNSC types going by the definition given in HelpCenter.
| Quote: |
| InputRoot, OutputRoot, and so on, are examples of ROW variables that are automatically declared and present in the data structure, ready for use. |
http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fak17815_.htm
When it says both InputRoot and OutputRoot are themselves a ROW type, it should support all types. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 04, 2012 2:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
time for a PMR then...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Aug 04, 2012 3:19 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Take a Trace node output of message. Does it show that the attribute elements have the field types that identify them as XMLNSC.Attributes? |
|
| Back to top |
|
|
| Memme |
| Posted: Tue Aug 07, 2012 1:08 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2012
Posts: 2
|
Hello everyone,
thanks for your fast and numerous replies.
I have "fixed" the problem by changing the structure of our code. Normally we call an esql module from the compute nodes of our flows, in which we call procedures/functions that actually execute some logic.
The same applies/applied to the logic I posted in my first post here.
I have removed this logic from the procedure and copied it into the esql module. Now it works by some miracle...
I do not understand why this is the case, as I expect calling a procedure (same logic) with the reference to OutputRoot should give me the same result.
Any ideas why this is not the case?
Thanks! |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 07, 2012 2:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Memme wrote: |
| I have removed this logic from the procedure and copied it into the esql module. Now it works by some miracle... |
"Miracle" is right. I didn't think you could use a ROW variable like that.
| Memme wrote: |
I do not understand why this is the case, as I expect calling a procedure (same logic) with the reference to OutputRoot should give me the same result.
Any ideas why this is not the case? |
What's the key differences between the user trace for the working and non-working case? Any ideas will start there.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
