| Author |
Message
|
| Brian1973 |
 Posted: Mon Oct 29, 2012 8:49 am Post subject: Wildcards in ESQL? |
 |
|
Newbie
Joined: 29 Oct 2012
Posts: 4
|
Hopefully this is an easy question, I accept all deserved NOOB ridicule if you just nudge me in the correct direction.
WMB 6.1
I am using this code to reference a certain field in the message:
| Code: |
| InputRoot.XMLNSC.EventTransaction.*:ItemData.ABCDocs.RouteFlag |
This works fine. The problem is that sometimes the message is different and it has XYZDocs instead of ABCDocs as the element name. The RouteFlag stays the same. There might be other names for this element other than the 2 listed as well.
RouteFlag is an attribute of ABCDocs or XYZDocs or whatever else comes along.
The pseudocode would be something like this, but this doesn’t actually work:
| Code: |
| InputRoot.XMLNSC.EventTransaction.*:ItemData. *.RouteFlag |
How do I make this generic enough to accept anything there? I need the RouteFlag, that is the only important field. I feel like I have tried many combinations of "*" ":" etc and nothing works.
| Code: |
In XSLT this code does what I want.
<xsl:if test="($routeFlag != 'Y')">
<xsl:message terminate="yes">Error=003:RouteFlag is not Y</xsl:message>
</xsl:if> |
Thanks very much for your help.
Brian |
|
| Back to top |
|
 |
| McueMart |
| Posted: Mon Oct 29, 2012 9:02 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
I would have expected this to work...
| Code: |
| InputRoot.XMLNSC.EventTransaction.*:ItemData.*.(XMLNSC.Attribute)RouteFlag |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 29, 2012 9:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
I would have expected this to work...
| Code: |
| InputRoot.XMLNSC.EventTransaction.*:ItemData.*.(XMLNSC.Attribute)RouteFlag |
|
I wouldn't, though I've been wrong before.
A simple solution would be:
| Code: |
| InputRoot.XMLNSC.EventTransaction.*:ItemData.[1].(XMLNSC.Attribute)RouteFlag |
Where [1] becomes whichever poisition the tag is in.
A more sophisticated solution would be something like this untested snippet:
| Code: |
| THE(SELECT E.RouteFlag FROM InputRoot.XMLNSC.EventTransaction.*:ItemData.[] |
for those situations where RouteFlag can be anywhere.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Brian1973 |
| Posted: Mon Oct 29, 2012 9:33 am Post subject: |
|
|
Newbie
Joined: 29 Oct 2012
Posts: 4
|
Thank you for your suggestion. I am sure this is the right direction but still doesn't work with the element name wildcard.
| Code: |
WORKS - SET RouteFlag2 = FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.ABCDocs.(XMLNSC.Attribute)RouteFlag);
DOES NOT WORK - SET RouteFlag = FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.*.(XMLNSC.Attribute)RouteFlag); |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 29, 2012 9:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Use a reference. YOu can then go to the first child, next sibling etc...
You can also read the tagname by using fieldname and fieldnamespace functions...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mgk |
| Posted: Mon Oct 29, 2012 9:49 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Can you post a larger section of your input message, as that may help see what is happening. My guess is that ABCDocs is not the FirstChild of ItemData. In this case you need to know that the '*' does not mean "search all child elements" to find one with the RouteFlag, it actually means "go to the first element, whatever its name." So you may need to use:
| Code: |
| InputRoot.XMLNSC.EventTransaction.*:ItemData.*[2].(XMLNSC.Attribute)RouteFlag |
if ABCDocs is the second element, *[3] if it is the third etc.
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 29, 2012 9:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I'd do it with a reference walking through the siblings. If the fieldname has a pattern (ending in Docs for instance) it should be relatively easy to pick the right children / siblings...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Oct 29, 2012 10:02 am Post subject: Re: Wildcards in ESQL? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| Brian1973 wrote: |
The pseudocode would be something like this, but this doesn’t actually work:
| Code: |
| InputRoot.XMLNSC.EventTransaction.*:ItemData. *.RouteFlag |
|
There seems to be an extra space in the ESQL reference; that might just be a posting error, but it won't work in the code.
If the wildcard matches more than one element, then that can cause problems; adding an index can help. (For example: ... .ItemData.*[<]. ...) The InfoCenter explains ESQL support for wildcards in more detail. A Trace node can provide the actual message tree structure, and a debug-level usertrace can show exactly how the message flow is resolving the ESQL reference. |
|
| Back to top |
|
|
| Brian1973 |
| Posted: Mon Oct 29, 2012 11:31 am Post subject: |
|
|
Newbie
Joined: 29 Oct 2012
Posts: 4
|
This works, thanks a lot everyone.
| Code: |
| FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.[4].(XMLNSC.Attribute)RouteFlag); |
Thanks for the info center link. The XSLT I posted will look for RouteFlag anywhere in the document. I will try out the SELECT .... statement as well. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Oct 29, 2012 1:57 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| Brian1973 wrote: |
This works, thanks a lot everyone.
| Code: |
| FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.[4].(XMLNSC.Attribute)RouteFlag); |
|
Really? That looks like a syntax error, due to a missing '*' or resolved name:
| Code: |
| FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.*[4].(XMLNSC.Attribute)RouteFlag); |
If it works without the extra '*', then the documentation needs updating.
| Brian1973 wrote: |
| The XSLT I posted will look for RouteFlag anywhere in the document. |
The posted portion of the XSLT doesn't actually do that. |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Oct 30, 2012 1:14 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| . In this case you need to know that the '*' does not mean "search all child elements" to find one with the RouteFlag, it actually means "go to the first element, whatever its name." |
Interesting stuff - thanks for the clarification. What confused me a tad was the infocenter:
| Quote: |
You can use the asterisk (*) wildcard character in a path element to match any name. For example:
InputRoot.XMLNS.*.Invoice.Value
matches any path element in which the invoices are contained. |
(http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.doc/ak04861_.htm?resultof=%22xmlnsc%22%20%22wildcard%22)
I might just be interpreting that wrong! |
|
| Back to top |
|
|
| Brian1973 |
| Posted: Tue Oct 30, 2012 6:44 am Post subject: |
|
|
Newbie
Joined: 29 Oct 2012
Posts: 4
|
both of these work, i don't understand the difference between the two.
| Code: |
FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.[4].(XMLNSC.Attribute)RouteFlag);
FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.*[4].(XMLNSC.Attribute)RouteFlag); |
|
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Nov 02, 2012 1:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| Brian1973 wrote: |
both of these work, i don't understand the difference between the two.
| Code: |
FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.[4].(XMLNSC.Attribute)RouteFlag);
FIELDVALUE(InputRoot.XMLNSC.EventTransaction.*:ItemData.*[4].(XMLNSC.Attribute)RouteFlag); |
|
The difference is that one of these is documented, and the other is not. If the first form happens to work without generating a syntax error, then that's a (happy?) accident, but it may suddenly stop working at some point in the future. That's less likely to happen with the second form. |
|
| Back to top |
|
|
|
|
