| Author |
Message
|
| jharringa |
 Posted: Wed Nov 07, 2007 10:51 am Post subject: "name" attribute coming through as "nametag&q |
 |
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
I'm guessing that there is some collision going on with reserved words and so the following is getting changed from:
| Code: |
<Attributes>
<Attribute name="Name1">1234</Attribute>
<Attribute name="Name2">2345</Attribute>
</Attributes> |
to:
| Code: |
<Attributes>
<Attribute nametag="Name1">1234</Attribute>
<Attribute nametag="Name2">2345</Attribute>
</Attributes> |
This happens when I just do a treecopy as such:
| Code: |
| SET OutputRoot.XMLNSC.Attributes = InputBody.Attributes; |
and it also happens when I do any other kind of copy operation. I turned on the debugger and once the message comes out of the MQInput node the attribute has been translated from "name" to "nametag" so it doesn't appear that there is anything that I can do about this.
Additionally, it appears that I can't actually reference that attribute unless I look for "nametag." (That is, unless I am not coding this correctly.) Here are a few of the ways in which I have tried to access this without looking for nametag (within a while loop) and they all return NULL (hence nothing is set):
| Code: |
SET OutputRoot.XMLNSC.Attributes.Attribute[I].(XMLNSC.Attribute)name = InputBody.Attributes.Attribute[I]."name";
SET OutputRoot.XMLNSC.Attributes.Attribute[I].(XMLNSC.Attribute)name = InputBody.Attributes.Attribute[I].(XMLNSC.Attribute)name;
SET OutputRoot.XMLNSC.Attributes.Attribute[I].(XMLNSC.Attribute)name = InputBody.Attributes.Attribute[I].(XMLNSC.Attribute)"name";
SET OutputRoot.XMLNSC.Attributes.Attribute[I].(XMLNSC.Attribute)name = FIELDVALUE(InputBody.Attributes.Attribute[I].(XMLNSC.Attribute)name; |
We are on Broker version 6.0.0.5.
Any help would be greatly appreciated. I tried searching for this and couldn't find anything so hopefully I'm just missing something and I'm just asking a n00b question. I am concerned that if I try and access InputBody.Attributes.Attribute[I].nametag that some time down the line IBM may change the method and my code will break. So, essentially, I'm looking for "the right way" to do this.
Thank you,
Justin |
|
| Back to top |
|
 |
| jharringa |
| Posted: Wed Nov 07, 2007 11:04 am Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
FYI:
This code works correctly but is probably not correct (in order to be futureproof):
| Code: |
SET OutputRoot.MQMD = InputRoot.MQMD;
SET OutputRoot.Properties = InputRoot.Properties;
CREATE LASTCHILD OF OutputRoot DOMAIN 'XMLNSC' TYPE Name NAME 'XMLNSC';
CREATE LASTCHILD OF OutputRoot.XMLNSC DOMAIN 'XMLNSC' TYPE Name NAME 'Attributes';
-- check for use in actual code (assuming that the previous lines are not in the existing code)
IF (EXISTS(InputBody.Attributes.Attribute[])) THEN
DECLARE Source REFERENCE TO InputBody.Attributes;
DECLARE Target REFERENCE TO OutputRoot.XMLNSC.Attributes;
DECLARE Iter INT;
DECLARE NumAttr INT;
SET Iter = 1;
SET NumAttr = CARDINALITY(Source."Attribute"[]);
WHILE Iter <= NumAttr DO
SET Target.Attribute[Iter].(XMLNSC.Attribute)name = Source.Attribute[Iter]."name";
SET Target.Attribute[Iter] = FIELDVALUE(Source.Attribute[Iter]);
SET Iter = Iter + 1;
END WHILE;
END IF;
RETURN TRUE;
|
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Nov 07, 2007 11:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I would put every instance where you use 'name' to refer to an XML element or attribute identifier in double-quotes to avoid any attempt by the ESQL parser to interpret it as the NAME reserved word.
So even on the left hand side of
| Code: |
| SET Target.Attribute[Iter].(XMLNSC.Attribute)name = Source.Attribute[Iter]."name"; |
Also, consider using REFERENCE and MOVE instead of looping over cardinality.
However, that might lead you writing stuff that looks like
| Code: |
| move myRef NEXTSIBLING Name 'name' |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jharringa |
| Posted: Wed Nov 07, 2007 12:23 pm Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
Are there some pitfalls to looping over cardinality or are you suggesting that due to this issue?
I guess I had left out that the following doesn't work either:
| Code: |
SET Target.Attribute[Iter].(XMLNSC.Attribute)"name" = Source.Attribute[Iter].(XMLNSC.Attribute)"name"; |
I'm guessing that this is what you had in mind:
| Code: |
-- Set the Version
SET OutputRoot.XMLNSC.(XMLNSC.XmlDeclaration)*.(XMLNSC.Attribute)Version = '1.0';
-- Set the Encoding in the XML Declaration
SET OutputRoot.XMLNSC.(XMLNSC.XmlDeclaration)*.(XMLNSC.Attribute)Encoding = 'UTF-8';
-- Create OutputRoot.XMLNSC.DecisionAttributes for Reference declaration
CREATE LASTCHILD OF OutputRoot DOMAIN 'XMLNSC' TYPE Name NAME 'XMLNSC';
CREATE LASTCHILD OF OutputRoot.XMLNSC DOMAIN 'XMLNSC' TYPE Name NAME 'DecisionAttributes';
-- Declare reference variables
DECLARE Source REFERENCE TO InputBody.DecisionAttributes;
DECLARE Target REFERENCE TO OutputRoot.XMLNSC.DecisionAttributes;
-- Attempt to move to the first Attribute element
MOVE Source FIRSTCHILD NAME 'Attribute';
-- Do while the last move was successful
WHILE LASTMOVE(Source) DO
-- create Target Attribute element with value from source
CREATE LASTCHILD OF Target DOMAIN('XMLNSC') TYPE NameValue
NAME 'Attribute' Value Source;
-- Move to the Target's newly created Attribute element
MOVE Target LASTCHILD;
-- Move to the Name attribute of Source
MOVE Source FIRSTCHILD;
-- Create name attribute on target with value from the Source
CREATE FIELD Target.(XMLNSC.Attribute)"name" VALUE Source;
-- Move back to the Attribute element
MOVE Source PARENT;
-- Move back to the DecisionAttributes element
MOVE Target PARENT;
-- Move to the next Attribute sibling (if possible)
MOVE Source NEXTSIBLING NAME 'Attribute';
END WHILE;
|
It's contact admin... but it works. Unfortunately it's not as dynamic as the tree copy but this format has been stable for years so it'll do the job.
The only thing that got me here is that if I explicity call out the type as NameValue as such:
| Code: |
CREATE FIELD Target.(XMLNSC.Attribute)"name" TYPE NameValue VALUE Source;
|
I get an unfavorable result:
| Code: |
<DecisionAttributes>
<Attribute>
1234
<name>Name1</name>
<Attribute>
<Attribute>
2345
<name>Name2</name>
</Attribute>
</DecisionAttributes>
|
Any ideas? The documentation says that attributes with values are NameValue types but the documentation is also describing the creation of fields with in the XML domain as opposed to the XMLNSC domain.
BTW, I think that you've answered all of my posts Jeff. I really appreciate your expertise. Thanks! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Nov 07, 2007 12:41 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Using references is going to be faster than using cardinality - that's why I mentioned it.
Every time you do [x], the internal model has to walk the entire tree starting at 1, and counting until it gets to x.
A reference avoids that.
It seems like you're having issues on both sides of the equation - both in identifying the source location correctly and in building the destination location correctly.
You might want to try using a Mapping node, honestly... If you don't want to deploy a Map, then you can look at the new IA9Y SupportPac to convert it to ESQL.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jharringa |
| Posted: Wed Nov 07, 2007 12:56 pm Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
We had been told that the mapping node would be the slowest in terms of performance. Is that not the case?
I understand that references will increase performance (and usually use SELECT statements where I can). We had received a recommendation to use CARDINALITY over climbing through with MOVEs so that is essentially why I favored that approach. I just assumed that there was some optimization going on in the CARDINALITY function.
This oddity is about the only spot where I've really had any real troubles (and we've been avoiding the usage of CREATE statements per recommendation). I hate to ask this, but is there something wrong in the code I posted? I thought that I had followed your recommendation.
I've only been using Broker since around February but I had thought I had picked up a good basic understanding (and maybe even some more advanced concepts) in regards to coding. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Nov 07, 2007 1:06 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm honestly not sure enough of my own ESQL right this second to want to say for sure if something is wrong with your code or not.
I'm a little distracted by other things.
The way to approach the problem is take your very simple sample messages here, and run them through a trace node - basicaly a flow with MQInput(XMLNSC)->Trace
Look carefully at the Trace output. I'd recommend sending it to a file.
Then add a compute node between the MQInput and the trace, and write a bunch of lines that do a whole bunch of SET Environment.Variables.TraceFieldX = ... something from the Input Message. Then make sure to include ${Environment} in the trace pattern.
You're not going to get a lot of optimization by using or avoiding using Create with Set... I don't think.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jharringa |
| Posted: Wed Nov 07, 2007 2:21 pm Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
| No worries. I understand. Again, I appreciate you taking the time to respond and offer suggestions. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Nov 08, 2007 5:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Code: |
| CREATE FIELD Target.(XMLNSC.Attribute)"name" TYPE NameValue VALUE Source; |
That code is specifying the field type twice. You should either use
| Code: |
| CREATE FIELD Target.(XMLNSC.Attribute)"name" VALUE = Source; |
or
| Code: |
| CREATE FIELD Target."name" TYPE XMLNSC.Attribute VALUE Source; |
You asked about NameValue nodes in an earlier post on this thread.
The XMLNSC parser never uses the raw NameValue field type. It uses XMLNSC.Field for simple elements, XMLNSC.Folder for complex elements and XMLNSC.Attribute for attributes. Well done for spotting that those topics were referring to the XML and XMLNS domains. |
|
| Back to top |
|
|
| jharringa |
| Posted: Thu Nov 08, 2007 7:32 am Post subject: |
|
|
Acolyte
Joined: 24 Aug 2007
Posts: 70
|
Thanks kimbert!
That will help tremendously. That would explain some other unexpected effects when trying to mix Name, NameValue, and Value types with the XMLNSC parser.
So if I understand you correctly I should not be doing this:
| Code: |
CREATE LASTCHILD OF OutputRoot DOMAIN 'XMLNSC' TYPE Name NAME 'XMLNSC';
CREATE LASTCHILD OF OutputRoot.XMLNSC DOMAIN 'XMLNSC' TYPE Name NAME 'DecisionAttributes';
|
but I should be doing this instead (so that I'm not specifying the domain twice and so that I am specifying a valid type):
| Code: |
CREATE LASTCHILD OF OutputRoot TYPE XMLNSC.Folder NAME 'XMLNSC';
CREATE LASTCHILD OF OutputRoot.XMLNSC TYPE XMLNSC.Folder NAME 'DecisionAttributes';
|
Also, (sorry to ask so many questions) what is the advantage of using "CREATE FIELD" over "CREATE LASTCHILD" (or NEXTSIBLING, etc...)? I saw in the document that FIELD would not necessarily create the field and the others would. So if I understand this correctly it sounds like if I tried to assign a null value in the CREATE FIELD statement then the folders leading up to the field would be created but the field itself would not be created. If I did the same with CREATE LASTCHILD it sounds like it would create any folders that did not exist up to the field, would create the field and then try to assign a value to it (so if a NULL is in the VALUE portion, the field would still exist). Am I interpreting that correctly? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 08, 2007 8:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You should use the DOMAIN clause to create OutputRoot.XMLNSC, and not anything else.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
