Fred Hartman addressed my questions in the following reply:
I can successfully invoke my validateAddress soap-msg based service from a command line test tool by posting the soap request message below (A). However, when I generate a WSDL file for this service (correctly pointing it to the appropriate input and output documents, it does refer to a prefix name anywhere (“xsq” in my case).
What do I need to do to my WSDL file to cause a client (.Net, webMethods, AXIS, whatever) to generate a soap message with a root node of “xsq:validateAddress” instead of just “validateAddress”.
There is no way to control the prefix naming of any node in soap messages. At least it is different in each SOAP implementation and any real XML implementation should work without caring about the prefix. As you know:
<xsq:validateAddress xmlns:xsq="uri:myNamespace">
is equivalent to
<validateAddress xmlns="uri:myNamespace">
So you ask, “How can I define a Flow Map if the fieldName changes from prefix0:validateAddress to xsq:validateAddress to validateAddress to p3:validateAddress? Just when I think it works, I get a source value is null warning.”
When calling documentToRecord you can pass a nsDecls parameter, which defines the namespace → prefix mapping. This means that the prefix of the incoming document is ignored when building the IData when the namespace of an element is found in the mapping list.
For instance,
nsDecls
xsq = uri:myNamespace
would produce a boundNode with an entry
xsq:validateAddress
for all the following incoming SOAP docs:
<prefix0:validateAddress xmlns:prefix0="uri:myNamespace">
<xsq:validateAddress xmlns:xsq="uri:myNamespace">
<p3:validateAddress xmlns:p3="uri:myNamespace">
<validateAddress xmlns="uri:myNamespace">
I think there was a bug in IS 4.6 and the nsDecls parameter was not getting generated for you. This is fixed in 6.0.1, but you have to fixup the generated Flow with 4.6.
If I post the soap message (B) shown below, the default processor locates and invokes my service OK, but when I try to use queryDocument against the body of the message, the “Document View” shows the structure of the document with every node prefixed by “prefix0:”. That would be OK, if I could query against it, but a query of “/prefix0:validateAddress” returns null. See the two attached bitmaps.
This is easy to recreate and a real pain in the rear.
the webMethods XQL implementation was done right about the time that XML Namespaces Note was first released. So it is made to work in two modes:
-
With no prefix/namespace mapping, so that the raw prefix:localName of the query are compared with the prefix:localName of each element. This makes thing simplier, but it means that if the prefix changes in the incoming document you have problems. With point-to-point integrations the prefix rarely changes, so people don’t have to ever really care about the namespace mapping. With SOAP every implementation picks prefixes differently, so it is an issue right away.
-
With a prefix/namespace mapping. This is the nsDecls parameter to queryDocument. You can pass an IData with keys as the prefix and value as the namespace. These are the mappings for use in the query, so in your instance you can pass
nsDecls
xsq =
#API-Management#soa#webMethods