| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Name Attributes Disappearing with MOVE. |
« View previous topic :: View next topic » |
| Author |
Message
|
| Orette |
 Posted: Mon Jan 28, 2019 12:34 pm Post subject: Name Attributes Disappearing with MOVE. |
 |
|
Newbie
Joined: 22 Mar 2017
Posts: 8
|
Without going too immensely in-depth, I have a backend call that gives me a response in the Enviornment. I have to loop through a select few of those responses, and I'm doing that in the Enviornment as well (see 'ResponseLoop' in the example below).
In the Environment, I have a structure like the following:
➧Environment
...➧BackendCall
......➧BackendRequest
......➧BackendResponse
......➧ResponseLoop
.........➧ABC
............➧SubCollection
...............➧Column.............................7800
...............➧Column.............................3210
...............➧Column.............................1051
...............➧Column.............................2223
............➧SubCollection
............➧SubCollection
The Columns each have a Name attribute. This is the way it is in the Environment.
When I attempt to DECLARE ref REFERENCE TO Environment.BackendCall.ResponseLoop.ABC, I can still see that the Columns have their name attributes. However, when I then MOVE ref FIRSTCHILD NAME 'SubCollection', all of the name attributes disappear.
I have looked around the forum and imagine that this has to do something with not setting DOMAIN 'XMLNSC' somewhere, but I am unsure where I would do that, and also unsure why the name attributes are present all the way up until I happen to MOVE into the SubCollection.
Let me know if I need to provide extra information. Thanks! |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jan 28, 2019 1:07 pm Post subject: Re: Name Attributes Disappearing with MOVE. |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Orette wrote: |
| I have looked around the forum and imagine that this has to do something with not setting DOMAIN 'XMLNSC' somewhere, but I am unsure where I would do that |
You wouldn't - whoever populates the Environment tree and creates this would do it
| Orette wrote: |
| unsure why the name attributes are present all the way up until I happen to MOVE into the SubCollection. |
So am I, but if I had to guess I would assume it's a feature of the on-demand parsing; that part of the tree is not parsed until you actually move into it and thereby notify the software you're interested in what it contains.
I also suspect you're seeing the tree in the Debugger output, which is notoriously unreliable when it comes to data or parsing problems. The Debugger has to interpret what's it's seeing in memory by parsing, and it doesn't always get the same results as the parser built into the runtime.
If you really want to know what it looks like, put a Trace node before your Compute node.
I also agree that the solution to retaining attributes is to put the tree in the XMLNSC domain (which supports them) rather then the default Environment domain (which doesn't)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| timber |
| Posted: Mon Jan 28, 2019 3:51 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
It's quite simple, but only if you know the answer...
- IIB message trees are *always* owned by a parser (XMLNSC, SOAP, DFDL etc)
- The parser type determines how IIB interprets the bit-fields in the TYPE attribute of each node. In XMLNSC, one of those bits means 'this is an XML attribute, and not an XML tag'
- To avoid horrible confusion, if you copy a message tree (or a fragment thereof) from a tree owned by parser A to a tree owned by parser B...IIB helpfully zilches all of the bits in the TYPE field. This avoids all kinds of surprising and and unwanted behaviour...
Unfortunately, that last rule gets applied even if the owner of the target message tree is MQROOT (i.e. no parser explicitly specified). This leads to a very common, very surprising and very unwanted behaviour when you copy an XMLNSC tree into the Environment, and then find that all your XML attributes have become tags.
The answer is
| Code: |
CREATE LASTCHILD OF myEnvironmentRef DOMAIN 'XMLNSC' TYPE Name NAME 'myXMLNSCwithAttributes' |
|
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Jan 28, 2019 5:44 pm Post subject: Re: Name Attributes Disappearing with MOVE. |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| Orette wrote: |
| The Columns each have a Name attribute. This is the way it is in the Environment. |
Does that mean that the "Name" element has a type of XML.Attribute, or XMLNSC.Attribute, or something else? A Trace node displays this element type information (and owning parser) more clearly.
| Orette wrote: |
| However, when I then MOVE ref FIRSTCHILD NAME 'SubCollection', all of the name attributes disappear. |
Simply re-pointing a reference variable from one element to another would not cause elements to disappear.
timber explained a common problem when copying a sub-tree from one location (source) to another (destination), where the source and destination sub-trees are not owned by the same parser. In that case, a tree copy might change the types of the elements in the destination sub-tree, but it still copies them; the elements don't just disappear. And it doesn't change the source sub-tree at all.
| Orette wrote: |
| Let me know if I need to provide extra information. |
If the problem seems to be due to some issue other than a tree copy with un-assigned parser(s), then please describe in more detail what the message flow does with the sub-tree(s), and try to narrow down exactly where the elements "disappear". |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
