We have a web service that outputs complex XML structure.
The output is of the form defined by an xml schema (internal to the web service).
This same XML schema has been used to generate a publishable webMethods document type within wm.
The problem is, the New Document wizard creates the document with prefix of “ns:”, while the web service connector wizard creates input/output documents with prefix “tns1:”.
This means we cannot do top-level mapping from one to the other… it has do be done at the leaf-node level which is frustrating given the number of nodes (and nested lists of nodes) involved.
The obvious way to fix this would be to update the web service connector nsDecls statements from tns1 to ns, however because the new web service connector wizard builds the flow service using references to tns1 throughout the flow and within the output document, there’s a bit more to it than that, and fiddling with tool-generated code has its pitfalls.
Is there a way to change the prefixes of a document? I guess a global search/replace across the document element names is required - sounds like a job for a java-service to me, as I don’t know any way to actually access/modify element names at run-time.
Otherwise, is there a way to edit the “template” that either the new document from xml schema wizard, or the new web service connector wizard, such that the default namespace prefix can be adjusted?
Any help appreciated, as we have numerous instances of this problem!
The “problem” seems to be related to unfamiliarity with working with namespaces and prefixes in IS. There are many posts here on doing similar things in Flow.
First, if you build your XML schema correctly by declaring a target namespace, associating a prefix with that namspace in the XSD and specifying an attribute of elementFormDefault=“qualified”, the new document wizard should pickup the prefix you would like to use.
Second, don’t use the web services connector wizard to generate sub-standard Flow. Write it yourself. In that way you can build the messages precisely the way you want.
Finally, when dealing with namespace-qualified elements, prefixes are interchangeable and you are never guaranteed to receive a specific prefix so long as the element is associated with the correct namespace either by default or by explicit declaration. You need to use the nsDecls parameter correctly to do this.
"specifying an attribute of elementFormDefault=“qualified”, the new document wizard should pickup the prefix you would like to use.
" …
…But how does it know which prefix we want to use? The prefix is defined in each instance, not the schema.
By the way, by specifying “unqualified” default form, does this mean that webMethods will not create prefixes at all? I’ll test this (as we’re currently using qualified), this might short circuit the whole issue.
With re: to web service connectors - is it common (or “best”) practice to avoid these? I’m loathe to write more flow by hand than I have to!
I understand your point about the prefix never being garaunteed to be anything specific, and I guess that’s kind of my point; Given this fact, isn’t it weird that webMethods locks the document into a specific one, at design time what’s more, as opposed to some “wildcard” approach eg *:elementName.
I suppose this would be fine if there was a simple method to “translate” between instances of the same XML schema but with different arbitrary prefixes - and if I knew how to write one myself I would ;-).
I’ve had trouble with nsDecls in the past, again because the design-/run- time issue, in a situation where I wanted to ensure the same prefix went out as what came in (ie ns: was not acceptable), but this was not necessarily known at design time. Because the prefix/namespace pair is not specified as a value pair, but the NAME of a value and the value, this means the prefix is not readily updatable at run time. In that instance I was able to write a java flow to generate the specific nsDecls for the destination document, based on the one retrieved from the source document.
When you use wizards to generate code, you can’t complain about the quality of that code. If you like the code generated by the WSC, use it. I don’t. Again, many posts on that topic here.
This isn’t a bug, but an inexperience issue. You don’t need any special workarounds, java services or other hacks.
If you want additional help, please provide more information about the task at hand. It’s not clear to me what you are trying to do. What does the web service you are consuming do? What are you trying to do with the results?
“When you use wizards to generate code, you can’t complain about the quality of that code” - I’m not sure I actually complained, nor did I suggest there are any bugs! And given I’ve asked a question of a more experienced user (if there was a way of customising the tool output to suit), I’m not sure there’s any need to further highlight my inexperience!!
The .NET web service I’m consuming generates SOAP structures based on a schema (let’s call it Schema X).
Schema X is suitable for use as our webMethods canonical form, hence we’ve used it to build our canonical publishable document type (let’s call that Document X). This document is created with ns: prefixes.
So, after the web service connector runs, we have a new document that matches the structure of Document X perfectly, except that it has tns1: instead of ns: prefixes.
At the end of the day, I just want an easy way to move the content of the retrieved document into my canonical document.
Under normal circumstances I realise I wouldn’t be able to avoid a mapping from one to the other using individual join-the-dots map steps.
But I just figured the circumstance where a particular web service delivers a suitable canonical form would not be unique (especially where the web service was developed in-house), and hence something may be available to help with this step.
Mapping from one document to another, where the only difference between the two documents is prefixes, seems like something that shouldn’t be that difficult (and I’m sure isn’t difficult if you have the know-how).
It might be helpful if you stop thinking about mapping document X from one form to another. Given what you’ve stated so far, such a mapping appears unnecessary.
As I understand it, you have created these elements using the wizards in Developer:
IS document type to define the structure and fields of DocX
A web service connector that invokes a web service, which has an output document that matches DocX in every way except that it uses tns1 as the prefix.
If this is the case, modify the output parameters of your web service connector to use the document type definition you created for DocX. Also, modify the web service connector to specify ns in the nsdecls paramater (I don’t recall exactly which step has this parameter). That way, no matter what the web service you call returns as a prefix, the document in the pipeline will always have the ns prefix. No mapping needed.
Hello - Just wanted some advice on a related question with automatically generated webservice connector namespaces and TN.
I generated webservice connectors from a WSDL. webMethods automatically prefixes data structure elements with ‘tns1’ or ‘xsi’ namespace. When I execute a webservice connector (say, GetOrder), webMethods puts the result into a datastructure that looks like this:
However, when I created a Trading Networks document type for this document, and attempted to test it with the XML above, TN throws a “Error: namespace prefix tns1 not defined for element GetOrderResult” error
The only way I can make TN accept the document is go away is by adding a namespace prefix to the XML (by using nsDecls input in the ‘pub.xml:documentToXMLString’ service) so that the XML looks like this. Then all is well.
