I’m trying to use an xml file that is based on a schema. Here are the steps that I went throught in WmDeveloper:
I made a new Document Type by specifying my xml schema. It created a webMethods Schema object and a Document Type. The document type seems ok. The “XML namespace” property is set to the good URI. The only strange thing is that all the names are prefixed with “ns:”. The document type is named “customer”.
I make a new service that returns a “custumer” document.
In the new service, I call “xmlStringToXMLNode” with a stream of a xml file that correspond to the right schema. The node is ok.
I then call “xmlNodeToDocument” with the “customer” “documentTypeName”. The resulting document is almost right. It does not have the same “ns:” prefix has the type I defined. When I test the service, the data is not in the defined service output.
If I add “nsDecls” with the “ns:” prefix to my call to “xmlNodeToDocument”, everything works right.
In xml, an element name belongs to a namespace. The prefix is a serialization artefact that should exists just at the xml file level. I should not have hardcode the prefix name in my call to “xmlNodeToDocument”. My first guess is that webMethods does not handle the namespace correctly. But maybe I don’t understand things correctly. What do you think?
You can prevent the prefixes from appearing in your generated doctype by creating the schema object first. Once the schema object exists, when you create the doctype, you shouldn’t get the prefixes.
I know this adds an extra step. I find it wierd myself.
Another option is you can do a replace in the xmldata string using replace service by specifying searchString=<ns: replaceString=null and also do the same for searchString=</ns: replaceString=null,then you call XMLStringToNode and XMLNodeToDocument this will work too and avoids no hardcode in nsDecls.
If you know the document type, which you have to because you are doing mapping on the document content, then you know the namespace you will be dealing with. What is wrong with hardcoding an nsDecls parameter? This seems the best way to make sure that all legal incoming XML are converted to a single format IData object in the pipeline.
nsDecls does not assume what the incoming document has used as a prefix, as using replace does, it defines what prefixed XMLNodeToDocument should use for the IData output field naming.
I’m trying to use OAGIS v9 Canonical Document.
I had some problems because of the recursive elements of v8, but v9 solved the problem.
Now I want to make it publishable, but broker doesn’t like it.
The cause might be due to the fact of the documents inside the bod are created as: “ns:ApplicationArea”, for example.
How can I overcome this problem?
How can I create the document types from the xsd, without it having the “ns:”.
There was a message mentioning to create the schema first and then create the document type. How can I do that in wM 6.1? After creating the schema, I cannot create the document type.
>>>Now I want to make it publishable, but broker doesn’t like it.
Pedro,
If you are referring to the “Warnings” that developer gives when making a document, containing fields that are invalid on broker, publishable- you can safely ignore them.
The downside is that, you cannot apply filters on such invalid fields at broker level. The documents and all fields will still be visible to Integration server and filters on those fields can be applied at trigger level.
Thanks for the input. I can now publish and subscribe to these document types, no problem, although I cannot see then when using other tools like Document Tracker. That’s all fine.
My next chalenge is to convert the document into an XML String, using the pub.xml:documentToXMLString. The resulting xmldata also has the “ns:” before the elements. How can I get arround this?
My problem is that we’re exchanging these xmf files with a business patner via TN. I don’t want to send them a file with the namespace.
Are you trying to remove the namespace prefix “ns” or are you trying to remove the xmlns:ns=“http://” namespace definitions? If you are attempting to follow OAGIS you would want to keep the namespace definitions to indicate which OAGIS standards version you are using. The prefix can be anything you want, but needs to be defined.
I’m trying to remove the ns: from the elements.
I want my trading partner to be able to assign a namespace to the xml if they want. There was a post about doing string manipulation when the doc is coming in. Maybe I can do the same, just before submiting it to TN.
And there is another problem. We’re using the same bod for Inbound and Outbound. If we have the namespace prefix in the outbound messages, we need to define the xpath for the sender and the receiver using the namespace.
In the case of Inbound, they will not have any namespace and TN defaults it as “prefix0”. We cannot have two queries for Sender and Receiver on the same document type.
Just an update on my last problem.
When configuring the Doc Type in TN, if I use an xml without the namespace, TN will default it as prefix0.
The good thing is, even if I submit an xml with elements like “ns:ProcessInvoice” (having an xmlns:ns=“http://” as well), the recognition of the sender and receiver is done successfully, even though the xpath for SenderId states “prefix0:Elem1/prefix0:Elem2”.
This will solve recognition of the Doc Type, Sender and Receiver.
The other problem still remains. How can I produce a clean xml file, where my elements do not have a prefix ,for example ns:Elem be only , having the xmlns=“http://”.
How to associate the document type with an existing xml schema that is created before? In domain, it gives two option. One to specify ‘Default domain’ which takes references from different package. Another to specify ‘specific domain’. Though I gave the previously created xml schema name, it again created a xml schema with the name of the document prefixed with schema. I have the same problem what Martin has explained.