In most of our orchestrations where we need to parse a message, let's say for storing data from the message in a database to loop through the records in the message, we use XML parsing. For that, we have the XpathNavigator class, or we can use XMLDocument's SelectNodes method which returns an iterator, and we can iterate the records in the XML. But, consider a complex XML, e.g., if there are many parent child nodes, and we have to dig deeper into the nodes, come back again to the parent, and use nested while loops for parsing the whole XML. Well, for a good coder, this won’t be much of a problem, but a messy coder like me will run into exceptions and bugs. :)
Well, how about if we take advantage of .NET Serialization/Deserialization? We pass the message as an XMLDocument object to our component method as a parameter, and we deserialize the XMLDocument to an object. But wait, which object? From where will this class come from? We just need a proxy class of the web message type. The proxy class will contain the web message type and all of its nodes, and then we can deserialize the XMLDocument object containing the XML into a much managed object which we can iterate easily. You can generate the proxy class from the Visual Studio command prompt and giving the proper switches will create the proxy class.
You can see the MSDN help for more switches of WSDL:
wsdl /out:[dir]proxy.cs http://localhost/[webservice URI].asmx?wsdl
If you notice, the Web Service URI is missing from the command, and we need a WSDL of the Web Service. A simple workaround for this is in our BizTalk Schema project in which the type of message (schema) is built and then a web message is published from the BizTalk Web Services Publishing Wizard. Just build your project and run the wizard. In the first step, select the “Publish schemas as Web Services” option. You will get a tree in the next step, and yes, the Web Service requires at least request and response schemas.
Right click the request schema and select the assembly (this assembly should be your BizTalk schemas project).
Select the root node of your schema. In the same way, configure the response message as well (of your own choice), and you are done.
In the next step, give the URI of the Web Service and then the hierarchy in your IIS.
By running the command given above, you will get the proxy class. Include this class in your component project (which will be most likely a .NET library project). (Note: If you don’t see your schema type class in the intellisense, do check the proxy class and your component project namespaces). In your components method which will be parsing your message, deserialize your XMLDocument object to the object type of the proxy class. This will be the Root node (if you have one) name of your schema. In my case, I used the code below. xdoc is the object variable name of the type XMLDocument which will contain my XML data. And, one more thing which I am sure most of the BizTalk guys will know is you can assign your message freely to the XMLDocument type variable in your orchestration.
IFX response = new IFX();
XmlSerializer xs = new XmlSerializer(response.GetType());
XmlNodeReader reader = new XmlNodeReader(xdoc.DocumentElement,"Namespace");
response = (IFX)xs.Deserialize(reader);
In the above code, I was receiving a response and wanted to insert the records from the response into my table. This made me comfortably access the inner child records and arrays of the XML. May be, you would get XMLDocument runtime errors. Do check your XML if it contains namespaces, in which case deserialization will give exceptions. To solve this, supply the namespace of the root node in the XmlNodeReader constructor.
Submit an article or tip
