Joe,
You have hit upon the wonderful world of xml and namespaces. Not an easy task but it is doable. As you have discovered the prefix is arbitrary and depends on the sending system. Whether it is fully qualified or not will determine if all elements have a prefix or like in the case of .Net a default namespace is used so no prefixes. It all varies depending on the vendor.
The queryXmlNode does work, you will need to wild card the search string for prefixes so that it will accept all prefixes or none. Something like - //:createRequest/:firstname/text() using xql will do the trick. This can be tedious for large documents. You can also use the getBodyEntries and loop over it mapping it to a Document using xmlNodeToDocument. You can then map that to a internal document and prefixes will not be brought over.
Mark C is the soap master, he may be able to offer some more insight.
By populating the nsdecls parameter of the pub.xml:queryXMLNode statement, with some prefix and an associated namespace, you should be able to successfully query documents that use the same namespace with a different prefix. Just use the prefix that you supply in the nsdecls parameter in your queries.
Thanks to Fred Hartman for teaching me this trick originally.
I haven’t done a whole lot with web services in webMethods, but I do have a comment/question: doesn’t webMethods IS automatically expose all services as web services out of the box? In other words, couldn’t Joachim simply develop a good, old flow service, give his client the URL needed to access his flow service as a web service, and then let the webMethods content handler worry about parsing the SOAP XML? I did this a few months ago and it seemed to work well.
Percio,
I think we are talking about two different things. Joe’s question was more related to parsing the xml once received and how to deal with namespaces and prefixes. Yours seems more related to the invocation of the service. I guess the term “exposed” is kind of confusing and gets into more of the definition of what is a web service. Without getting to verbose here, one of the key ingredients to a web service is the contract ie the WSDL.
The integration server doesn’t generate this automatically. It is done through the developer and then given to the clients interested in invoking the web service. This is really a key part of a web service because it defines the message structure, message exchange, service endpoints etc that the client and the service provider agree to adhere to. If done correctly it really abstracts the client from the provider in this case the integration server.
Another point is the type of web service you want to expose. Pretty much the standard in the web services space is doc/literal or doc/literal wrapped. If you want to insure interoperability and try to adhere to some industry standards like the basic profile then that is the way to go. This again is not the default construction of a typical Integration Server flow service, it requires some extra work.
It is correct to say that you can invoke any IS Flow or Java service using a soap-rpc soap message. However, in order to expose that service you need to manually generate a WSDL file that can be shared with the service consumer.
In addition, as Mark G points out, the soap-rpc style of web services is not as well accepted or as interoperable as the document/literal style. So, yes, technically, every IS service can be invoked as a soap-rpc style web service, but in the real world, that doesn’t buy you much in terms of having those services be accessible by consumers across the enterprise.
I would love to see a future release of Integration Server that makes exposing a folder full of IS services as doc/literal web services and dynamically generating a highly interoperable WSDL file describing those services unbelievably easy to do. Having built IS soap processors that do much of what is needed to achieve this, I hope the folks in product development won’t settle for anything less than this in the next release.
many thanks for all your quick posts and for your work. You gave me many information to handle my problem. I will try and integrate and I will post my solution, when I have fixed.
One other problem I have seen, might be a bug in wM.
I made a query to my received document with queryXmlNode looking for prefixes. The xql command is //prefix(). I read the result into a variable named prefix. The variable is successfully set.
Then I would like to use this variable in xmlNodeToDocument setting nsDecls with %prefix% and my namespace. I use the checkbox ‘perform variable substitution’, but %prefix% is not substituted.
You can’t (easily) dynamically create an nsdecls document using Flow alone since %prefix% is actually the key portion of an IData entry.
I created a simple java service that accepts a single prefix and a single namespace and returns an nsdecls document suitable for mapping into any service that accepts one. You could obviously tweak this to accept an array of prefixes and namespaces.
Hope you find the attached example helpful. No warranties given or implied.
create nsDecls example