| Author |
Message
|
| mqjeff |
 Posted: Tue Jun 11, 2013 5:59 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| schroederms wrote: |
I appreciate everyone's help, I've got it doing what I need to have it do. Completely namespace independent (multiple namespace possible from a third party company), which I then loop through whatever the tag names are under REQUEST.APP, removing the name space, and building a message to feed into SAP.
Thanks Again! 
Set Environment.MyloopStart = Cardinality(InputRoot.XMLNSC.(XMLNSC.Element)*:*.*:REQUEST.*:APP.*:*[]);
--Pull all data under REQUEST.APP and prepare for SAP feed.
While i <= Environment.MyloopStart Do
Set Environment.APP.[i] NAME = Fieldname(InputRoot.XMLNSC.(XMLNSC.Element)*:*.*:REQUEST.*:APP.*:*[i]);
Set Environment.APP.[i] = InputRoot.XMLNSC.(XMLNSC.Element)*:*.*:REQUEST.*:APP.*:*[i];
set i = i +1;
End While;
Set OutputRoot.XMLNSC.(XMLNSC.XmlDeclaration)*.(XMLNSC.Attribute)Version=InputRoot.XMLNSC.(XMLNSC.XmlDeclaration)*.(XMLNSC.Attribute)Version;
Set OutputRoot.XMLNSC.(XMLNSC.XmlDeclaration)*.(XMLNSC.Attribute)Encoding=InputRoot.XMLNSC.(XMLNSC.XmlDeclaration)*.(XMLNSC.Attribute)Encoding;
--
--
Set OutputRoot.XMLNSC.REQUEST.APP = Environment.APP; |
That's great except it's entirely and absolutely the wrong way to write a Loop over message trees in ESQL.
NEVER USE CARDINALITY. NEVER USE [<value>] for an incrementing value.
NEVER.
ALWAYS use Reference variables. Particularly in v8, the FOR loop is awesome.
Using [<value>] means you have to start at [1] each time, and count up to <value>, and then when you get to <value+1> you have to start at 1 and count up to <value+1>.
DO NOT USE THIS CONSTRUCT IN LOOPS. EVER. |
|
| Back to top |
|
 |
| schroederms |
| Posted: Tue Jun 11, 2013 6:21 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
So were are never to use Cardinality to determine a size? I understand the expense at running it over and over again, but that is why I ran it once and stored off the value. We've been doing that, and taught that way since version 2.
I'm willing to learn, do you have an example that covers the proper way of doing this then using the methods you spoke of?
They (IBM) still uses Cardinality in CopyMessageHeaders.
thanks. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 11, 2013 6:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| schroederms wrote: |
So were are never to use Cardinality to determine a size? I understand the expense at running it over and over again, but that is why I ran it once and stored off the value. We've been doing that, and taught that way since version 2.
I'm willing to learn, do you have an example that covers the proper way of doing this then using the methods you spoke of?
They (IBM) still uses Cardinality in CopyMessageHeaders.
thanks. |
It's fine to use cardinality to determine a size. It's terrible to then use that as a limit for a loop counter.
CopyMessageHeaders is written with the knowledge that there will only ever be a comparatively small number of children. And is also included as a shortcut, not as an example of best practice.
| Code: |
create lastchild of Environment DOMAIN('XMLNSC') Name 'APP';
FOR myRef AS InputRoot.XMLNSC.(XMLNSC.Element)*:*.*:REQUEST.*:APP.*:*[] DO
CREATE Lastchild of Environment.APP from myRef;
END FOR;
Set OutputRoot.XMLNSC.REQUEST.APP = Environment.APP; |
|
|
| Back to top |
|
|
| schroederms |
| Posted: Tue Jun 11, 2013 6:30 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 11, 2013 6:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| schroederms wrote: |
| thank you. |
that's off-the-cuff, might not be 100% correct in function. But should pass syntax validation... |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jun 11, 2013 7:10 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
You don't need to build up the output message in the Environment tree - you can create it directly under OutputRoot.XMLNSC.
| Code: |
FOR inputRef AS InputRoot.XMLNSC.(XMLNSC.Element)*:*.*:REQUEST.*:APP.*:*[] DO
CREATE lastchild of OutputRoot.XMLNSC.REQUEST.APP from inputRef;
END FOR; |
You may need one extra line to set the namespace to the empty string.
For bonus points, you can make the copying of the XML declaration a lot simpler too:
| Code: |
| CREATE lastchild of OutputRoot.XMLNSC from InputRoot.XMLNSC.(XMLNSC.XmlDeclaration)*; |
Same comment as mqjeff - this is untested code, so don't expect it to work  |
|
| Back to top |
|
|
| schroederms |
| Posted: Tue Jun 11, 2013 7:49 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
| Kimbert, yours does not bring the tags under APP across, mqJeff's does. mqJeffs does also bring the names space across though as well. |
|
| Back to top |
|
|
| schroederms |
| Posted: Tue Jun 11, 2013 8:00 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
| Correction..... Both work, bringing name space across. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jun 11, 2013 8:01 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Phew - I was starting to think that I was going mad for a moment. |
|
| Back to top |
|
|
| schroederms |
| Posted: Tue Jun 11, 2013 8:06 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
| what is the most efficient way of nulling out NS then? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 11, 2013 8:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| Phew - I was starting to think that I was going mad for a moment. |
I'm not sure this counts as sufficient proof either way. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Jun 11, 2013 8:17 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
|
| Back to top |
|
|
| goffinf |
| Posted: Tue Jun 11, 2013 8:18 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| schroederms wrote: |
| I appreciate everyone's help, I've got it doing what I need to have it do. Completely namespace independent (multiple namespace possible from a third party company) .... |
What's the point of having a message exchange specification that requires namespace association (presumably to help ensure the correct data domain semantics) if, on receipt you are processing all messages as namespace agnostic. Whilst I recognise the issues in processing messages from more than one namespace (and those which use multiple namespace within each message), it is hardly an unusual problem (think versioning). it seems an odd design choice to solve it by assuming all information items with the same name are semantically equivalent. If you cam be certain that is always the case, why design the messages with namespace associations in the first place ?
Fraser. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jun 11, 2013 8:35 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
I was assuming that you only wanted the namespace removed from the top-level tag.
If you are removing the namespaces everywhere then I agree with goffinf - you should be asking questions about where this requirement is coming from. |
|
| Back to top |
|
|
| schroederms |
| Posted: Tue Jun 11, 2013 9:58 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
| The namespace is coming from a third party, the SAP interface (once here) cannot except them, it is not a SAP webs service, this is whey they need to be removed. |
|
| Back to top |
|
|
|
|
