Santosh Benjamin

BTS Diary II - 8 - ns0 namespace

Whew.. this is a record for me. Two posts in the same day. Well, it has been a rather busy weekend trying to sort out my new laptop and make some progress on a serialisation issue i've been having. Thought i'd post about it cos it might make interesting reading for any Biztalkers in a similar situation out there.  It also looks like this issue is still floating around on newsgroup posts (in fact I just came across my post on this subject last year and nothing much has happened since then).

[Update: Since this post, I've managed to solve the problem. So i've done an edit to put in the resolution]

Heres the situation

(1) You publish an orchestration as a webservice. The schema of the message is fully qualified
(2) You submit data via a . NET component. In the processing of serialising data you use the correct namespaces in the XmlSerializer. 
(3) The orchestration recieves the data and throws an exception since the ns0: prefix is missing from the root element although it is there as a prefix for the main namespace (ie) it is there in xmlns:ns0="xyz".

A similar problem exists when you send data from inside Biztalk to an external component and find that the XML cannot be deserialised into the corresponding class because the parser crashes when it sees the ns0:.

So what do you do? Some people have a separate message for the webservice which has no targetNamespace at all and then manage to map it into a a more strongly qualified message in the orchestration. The problem i had last year was that when we opened the map again it threw all sorts of weird script errors and sometimes wouldnt compile. At that point we were sending data to an external system so we had to resort to a hack. We changed the component to accept an XmlDocument and then wrote another little helper to strip out the ns0 and sent the message on. This worked fine, but its a hack and i still find it distasteful.

Today Im in the situation where i need to submit data via a strong typed webservice to an untyped ASMX sitting on top of an orchestration.Sending the data to the strong typed facade is not a problem. But from there, I need to send it to the XmlDocument interface and just serialising the recieved object with a correct namespace doesnt solve the problem because we cannot prefix with ns0.

Resolution: To solve this we had to revisit the namespace declarations and ensure that all elements were prefixed correctly. Additionally, in Biztalk we had to make sure that the schemas were set to Elements - Qualified and Attributes- Unqualified. In a couple of our schemas the targetNamespace was redefined in another part with another prefix. All of this contributed to Biztalk not understanding the schema. When you send data to an external webservice, if you import the webreference, Biztalk creates the necessary schemas so all we need to do is map our internal message to the WS message and if there are prefixed elements in the schema definition, they will be prefixed in the transmitted message. If you are sending serialised data into an untyped message (Xmldocument input) or where the webservice takes a string as input (debatable practice, I know!!) , then the ns0: will go across in all the elements. However, if you use the same XSD on the other end, then you shouldnt have a problem in deserialising the data. In our old project, there was probably some foul up in the recipient schema which caused the serialisation problem. Its also worth experimenting more with XmlNameTables and suchlike to ensure the elements get mapped correctly.

Hope this helps someone in a similar situation.