Parsing BizTalk Messages in .NET Components Through Orchestration
This article discusses how to parse BizTalk messages in .NET Components through Orchestration.
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 this purpose, we have XpathNavigator class or we can use XMLDocument SelectNodes method, which returns an iterator and we can iterate the records in the XML. But consider a complex XML. For example, 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 like 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 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 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 webservice 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, which contains the type of message (schema) is built and then a web message should be 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 a 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 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 xml document runtime errors. Do check your XML that if it contains namespaces then deserialization will give exceptions. For this supply the Namespace of the root node in the XmlNodeReader constructor.