| Author |
Message
|
| IBM_Newbie |
 Posted: Wed Dec 07, 2011 8:40 pm Post subject: Setting Output tree dynamically from Environment tree |
 |
|
Novice
Joined: 05 Dec 2011
Posts: 15
|
Hi,
I need to create the Output tree dynamically from Environment tree.
ie
If my Environment is like this
Environment.A
Environment.B
Environment.C
My Output should be
OutputRoot.XMLNSC.Something.A
OutputRoot.XMLNSC.Something.B
OutputRoot.XMLNSC.Something.C
If there is another field added in Environment ie Environment.D, mu output root should take that automatically.
Please suggest a way |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Wed Dec 07, 2011 8:45 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
When you create an ESQL Compute node, some default code comes with it. Inside this default code is an example of how to loop through InputRoot. Loop through environment the same way and attach each Evenironment element to an OutputRoot element. Use the CARDINALITY function to determine the number of elements.
By the way, why have you not attended the WM663 class ?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Dec 08, 2011 1:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
I'll say it before mqjeff does...
CARDINALITY is fine if you're dealing with a small number of elements. Otherwise, you'll get much better performance by walking the elements using a REFERENCE variable. |
|
| Back to top |
|
|
| MrSmith |
| Posted: Thu Dec 08, 2011 3:36 am Post subject: |
|
|
Master
Joined: 20 Mar 2008
Posts: 215
|
and to expand on kimbert and preceding any reply from mqjeff  try using a FOR loop which will loop through all your "occurences" and as part of its syntax provides the said reference as indicated by kimbert
something like
| Code: |
FOR myEnvironRef AS Environment.Something[]
DECLARE namething CHAR FIELDNAME(myEnvironRef );
SET OutputRoot.XMLNSC.Something.{namething } = myEnvironRef.{namething } ;
END FOR;
|
Might not be exactly correct and has not be tested but you get the idea
You will see that I have put something after the Environment as for standards sake ypur Enviornment should have been populated with something like below where Variables is the at least the first child of Environment, just makes it neater
Environment.Variables.Something.A
Environment.Variables.Something.B
Environment.Variables.Something.C
so as to distinguish between other variables that may need to be stored there or have been by previous nodes.
_________________
-------- *
“Outside of a dog, a book is man's best friend. Inside of a dog it's too dark to read.” |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Dec 08, 2011 4:01 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5543
Location: Southampton
|
myEnvironRef is already pointing at the correct item. I think this is what you meant ( with the indentation that you also probably meant ):
| Code: |
FOR myEnvironRef AS Environment.Something[]
DECLARE fieldname CHAR FIELDNAME(myEnvironRef );
SET OutputRoot.XMLNSC.Something.{fieldname} = myEnvironRef;
END FOR; |
Not tested, of course. |
|
| Back to top |
|
|
| inMo |
| Posted: Thu Dec 08, 2011 10:25 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| Code: |
FOR myEnvironRef AS Environment.Something[]
*DECLARE* fieldname CHAR FIELDNAME(myEnvironRef );
SET OutputRoot.XMLNSC.Something.{fieldname} = myEnvironRef;
END FOR;
|
Can you actually use DECLARE within the FOR? I've always run under the assumption you'd need DECLARE outside the FOR, then use SET inside (on each occurence to avoid declaring what is already there). Just curious if i've discovered more evidence for how bad assumptions can be? |
|
| Back to top |
|
|
|
|
