Query on SOAPBody with different prefixes

, ,
1

I have created a web service with MSG protocol, in that web service I have mentioned “tn” as a prefix. I created the webconnector for that web service, when I call this web service through this web connector I get the SOAP Request and I am able to do the query on the body of this SOAP Request because it has the prefix “tn” as indicated in the WSDL. The problem is that when I gave that same WSDL to DotNet developers, they created a web reference through the same WSDL but some how DotNet eliminated the “tn” and used the “prefix0” as a prefix when calling my web service. Now I can also do the query on that but my problem is if different applications calls this web service they wouldn’t have the same prefix since I have seen in case of Dotnet where they replaced the original prefix and placed their own.

I was hoping if some how I can do the XQL or WQL query where I don’t have to be dependent on prefix. Has someone come across this kind of problem ? Mark really looking forward for your reply. I am using webMethods IS 6.1 on Windows 2000 operating system.

2

You can (should) force the incoming prefixes to be the strings you want by associating the namespace with the desired prefix in the call to pub.xml:xmlNodeToDocument. Review the IS BIS Reference for that service and the description of the nsDecls input parameter.

3

As Rob pointed out, the trick is to populate the nsDecls parameter on either the pub.xml:xmlNodeToDocument or the pub.xml:queryXMLNode parameter. If the namespace matches that on the incoming document, the prefix you assign in the nsDecls document will be used instead of the one in the incoming document.

Another approach is to use a wildcard ( “*”) character in the XQL query used to extract a portion of the XML document. That will match any prefix on the incoming document. This effectively ignores the prefix and namespace of an element which could yield unpredictable results if two elements with the same name but different prefixes existed in the same document (unlikely, but legal XML and quite possible).

HTH,

Mark

4